Scheduler fixes for hyperthreading

Stephan Uphoff ups at tree.com
Sun May 22 18:34:08 PDT 2005


On Sat, 2005-05-21 at 23:25, Colin Percival wrote:
> Stephan Uphoff wrote:
> > Would it be enough to disable access to RDTSC for user processes?
> 
> On single-core systems (single socket, not dual-core), yes.  Otherwise, no.
> 
> > I believe the attack needs a very exact time source.
> 
> It needs ~100 cycle resolution.  If you have two processors, you can get
> good enough precision for the attack by constructing a "virtual TSC" by
> using a second thread which repeatedly increments a location in memory.

OK

> > Beside benchmarking - is there any other real use for RDTSC ?
> 
> Some (broken) software uses the TSC in combination with external events in
> order to obtain entropy for cryptographic key generation.  As a result,
> disabling RDTSC could lead to non-obvious but very problematic breakage.

Both bde and phk seem to agree with you that just disabling RDTSC is not
an option :-(

However I am still wondering if single core, single socket
hyperthreading systems may not benefit from "on demand" enabling of the
RDTSC. This way threads from different processes that do no use RDTSC in
userspace can be scheduled concurrently. The extra work may make this
scheme unworkable - but it think it is worth to keep in mind.

> > I have to think more about possible scheduler changes.
> > Currently we don't even  know if a thread running on another virtual CPU
> > is in the kernel or not.
> > Throwing preemption, interrupt and kernel threads, pinned
> > threads,priority inheritance and the IPIs in the mix make correct and
> > efficient hyperthreading safe scheduling difficult.
> > This also looks like a lot of work and I am wondering if it would not be
> > better spend on other scheduler improvements.
> 
> If nobody wants to do this, then we could always just keep on telling our
> users "sorry, hyperthreading is broken on multi-user systems".  I don't
> mind, personally -- I only have one system with a hyperthreaded cpu, and I
> have hyperthreading turned off for performance reasons. :-)

I enable/disable hyperthreading on my dual Xeon test box to stress the
scheduler but haven't really measured performance differences.
Maybe we should ask on stable/current if anyone would be upset ...
While I am starting to have a few ideas on how to modify the 4bsd
scheduler working on it is not my priority.
However should re@ decide that this is really a must have feature I am
willing to give it a try.

Stephan



More information about the freebsd-arch mailing list