DragonFly BSD
DragonFly commits List (threaded) for 2004-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: cvs commit: src/sys/conf options.i386 options.pc98 src/sys/i386/conf GENERIC src/sys/i386/i386 machdep.c mp_machdep.c

From: David Rhodus <drhodus@xxxxxxxxxxx>
Date: Sun, 11 Jan 2004 12:45:59 -0500

On Jan 11, 2004, at 12:05 PM, Jeroen Ruigrok/asmodai wrote:

-On [20040109 22:02], David Rhodus (drhodus@xxxxxxxxxxxxxxxxxxxxxxx) wrote:
 	The idea is taken from JHB's changes in FreeBSD but without
 	the idle loop changes so as not to get the "Hyerthreading
 	slowdown" affect FreeBSD seems to have with HTT.

I have no idea what he did, but from what I gather from various resources is that with a lot of idleness you might want to halt the respective cores a little bit more than usual to not contend too much over the CPU core resources shared by both virtual CPUs.

This has been taken care of already in DragonFly, and a lot easier because of LWKT already having the per-cpu scheduling we use an IPI message. Just take a look at the at cpu_idle function inside machdep.c

        struct thread *td = curthread;

        KKASSERT(td->td_pri < TDPRI_CRIT);
        for (;;) {

if (cpu_idle_hlt && !lwkt_runnable() &&
(td->td_flags & TDF_IDLE_NOHLT) == 0) {
* We must guarentee that hlt is exactly the instruction
* following the sti or we introduce a timing window.
__asm __volatile("cli");
__asm __volatile("sti; hlt");
} else {
td->td_flags &= ~TDF_IDLE_NOHLT;
__asm __volatile("sti");

With this we when are able to have the scheduler wakeup a target cpu.
So then if a thread wants to run on a particular cpu we just IPI that cpu.
This is why the idle loop changes don't apply here anymore, because
we actually have fixed the performance issue with HLT'ing.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]