Messages in this thread | | | Date | Fri, 26 Jun 1998 11:03:43 +0100 | From | "Stephen C. Tweedie" <> | Subject | Re: kswapd's priority |
| |
Hi,
Linus, is rt priority inversion an issue which concerns you in the slightest for 2.2, a 2.3 feature, or a red herring as far as you are concerned?
On Fri, 26 Jun 1998 05:43:33 +0200 (MET DST), MOLNAR Ingo <mingo@valerie.inf.elte.hu> said:
> this is a much more far-reaching problem if we consider more complex > setups, like a system with both kswapd and raid5d (and/or nfsd).
> where i think it gets a bit problematic is when we have shared objects > like a page in the page cache.
Ignore kswapd for now; even with just nfs on its own we have a problem.
Consider a system with two realtime processes running at different priorities; as soon as the higher priority process tries to access an nfs object, it has to stall pending servicing by one of the nfsiod threads. At this point, of course, the lower priorty rt process can spin, blocking progress entirely.
This nfsd/raid5d issue is independent of kswapd.
Now, it's fairly clear how we can do priority inheritance if there is only one process responsible for waking up any specific wait-queue. Things get far more complex if that property does not hold. How, for example, do we manage priorities in the case of nfs clients where we have 5 nfs rpc threads by default, all of which may be busy servicing somebody else's low-priority request at the time the realtime process makes an nfs IO? We'd have to be able to assign groups of processes to groups of wait-queues in order to propogate the priority of any realtime process which blocks on one of those wait-queues.
Nasty. Achievable, but still nasty. Implementing the wait-queue groups is pretty straightforward, but doing the propogation would require a thorough inspection of all the places where a process might block on any kernel daemon. Fortunately the number of such daemons is limited.
--Stephen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |