Date: Fri, 17 Dec 2004 11:58:46 +0530 From: Joseph Koshy <joseph.koshy@gmail.com> To: freebsd-arch@freebsd.org Subject: Eventhandlers for CPU state changes Message-ID: <84dead7204121622283c51d41a@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?84dead7204121622283c51d41a>