Scheduled ideas: Two threads with one "stone"

[Zaphod Beeblebrox]

W.R.T. hyperthreading, it's come to my attention that FreeBSD has had some
recommendations for awhile --- namely hyperthreading is bad for secure
systems.  That-is-to-say this is not about recent vulnerabilities of recent
Intel flavoured CPUs, but rather some thoughts on a different solution to a
different problem.

I was building world on my laptop when I noticed how sucky it had become.
Now... I well know this is due to the fact that even a "nice -19 make -j32
buildworld" will slow the normal priority userland down by about 1/2
because the thread that is "me" on the CPU is competing with one of the
threads that is saturating the CPU.  My normal priority thread will get
scheduled, but it competes equally for resources with threads at much lower
priority.

It then struck me that the fix for this problem would also address the
hyperthreading side channel attack.  It struck me that two simple rules
would apply to scheduling hyperthreads (rather than the global "turn them
off for security" ...

To be scheduled on a paired hyperthread, the candidate thread should:

   1. Belong to the same user
   2. Be the same (or the same within a margin) effective priority

My argument here for (1) is that it makes the hyperthreading side channel
attack moot.  The same user has many ways to access the other process...
the hyperthreading attack would just be a waste of time.  My argument for
(2) is that it would restore the experience of responsiveness the local
machine that we have on non-hyperthreading processors.