>Using idprio as Volodymyr suggested seems to be a viable workaround. You
>mentioned in another message that idprio could potentially deadlock my
>machine, though. Under what conditions could this happen (and how likely
>is it to occur)?
idprio can lead to a system hang due to priority inversion. For example,
suppose that an idprio process does disk I/O and locks a critical resource
(such as the vnode for the '/' directory) prior to doing that. Then also
suppose that a normal process is in a permanent run state (loop: goto loop).
When the I/O completes on the idprio process, it will never be given an
opportunity to release the vnode lock. Eventually just about everything in
the system will deadlock waiting on that resource and the system will
essentially hang. The work-around for this is to temporarily increase the
priority of idprio processes while they execute in the kernel, but this
hasn't yet been implemented.
The above scenario can happen pretty easily if you have an idprio process
doing a normal mix of file operations - all you need then is normal priority
process(es) to eat all the CPU for long periods - even a few seconds can be
very annoying to interactive users.
-DG
David Greenman
Co-founder, The FreeBSD Project - http://www.freebsd.org
Manufacturer of high-performance Internet servers - http://www.terasolutions.com
Pave the road of life with opportunities.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
