Eventhandlers for CPU state changes

John Baldwin jhb at FreeBSD.org
Fri Dec 17 08:30:52 PST 2004


On Friday 17 December 2004 01:28 am, Joseph Koshy wrote:
> We currently allow CPUs to be enabled and disabled via the
> sysctl "machdep.hlt_cpus".  CPU enabling and disabling can
> happen at any time in our current design.
>
> It would be useful to have an eventhandler hook so that kernel
> modules can get notified when a CPU is enabled or disabled.
> For example, schedulers, memory allocators and drivers that
> use MSRs inside the CPU could use this information.
>
> Here is a straightforward attempt at implementing such an
> eventhandler:
>     http://perforce.freebsd.org/changeView.cgi?CH=67118
>
> The question however, is about the right kind of semantics for
> such an eventhandler  (The eventhandler above is at best
> "advisory" in nature).
>
> When we notify a module that "CPU X is going to go away", we
> may still want to allow that module to run on that CPU to cleanup
> some state (e.g., disable some MSRs).  However we may also wish
> to prevent other kernel threads from getting scheduled onto the
> to-be-disabled CPU inadvertently.
>
> One way of getting around this problem is for schedulers to register
> two eventhandlers.  The first with priority EVENTHANDLER_PRI_FIRST
> marks CPU X as about to be disabled.  Threads will not then get scheduled
> onto CPU X unless bound to it.  The second with priority
> EVENTHANDLER_PRI_LAST will actually disable CPU X.
>
> Suggestions?  Comments?

I think this is a good first step to getting ULE to work with the hlt_cpus 
stuff.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org


More information about the freebsd-arch mailing list