[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: scheduler support to lock user processes out?
On Thu, Feb 21, 2008 at 02:54:44PM +0000, Andrew Doran wrote:
> On Thu, Feb 21, 2008 at 06:27:41AM -0700, M. Warner Losh wrote:
> > Correct. FreeBSD's giant won't solve this problem, nor will NetBSD's
> > biglock when it covers less of the kernel.
> We already have drivers that don't take kernel_lock and it's easy to switch
> it off. Even for the vast majority of drivers that run rith it, acquring
> kernel_lock doesn't have the intended effect.
> The lesser hack of suspending user activity can be handled by adding another
> LWP state. We can't abuse the SUSPENDED or STOP states because they are used
> by applications. We can do something like:
> - Offline all but the current CPU.
> - Disable preemption. At this point there is only one user LWP left running
> in the system, the LWP that requested the suspend.
> - Transition all but non-critical LWPs to the new state PAUSED (or whatever
> it's called). This would need to include a number of kernel threads, for
> example those handling ktrace. It would need to skip others, like the
> cross call threads.
When I was writing code to allow an embedded system to sleep (not netbsd)
I used what was basically a rw sleep lock  to control the drivers.
Before any hardware access the process-level code would acquire it for
read, and release after the block of work was done.
The sleep code would acquire it for write - effectively blocking all the
The sleep itself was done by a very high priority process.
 you really need 'write-preference' as well.
David Laight: david%l8s.co.uk@localhost
Main Index |
Thread Index |