> I think there's a better way to fix it, and it's already high up my 2.1
> bugfix list. Before 2.2, I should be fixing kswapd to have a base
> priority which is the lowest possible realtime priority, but to
> temporarily inherit the priority of the highest priority task waiting
> for memory. That will make sure that it has the correct realtime
> priority at all times. ("Priority inheritance" is a standard and well
> known solution to the "priority inversion" problem in realtime systems.)
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. Say a 'normal' process reads in some shared
page, which gets delegated to say nfsd or raid5d. At this point we have
clear 'cause -> action' relationship, raid5d inherits the (quite low)
priority of that 'normal' process. Now, a bit later, a RT process comes in
and wants to have the very same page, it will just see the page is locked
and will add itself to the waitqueue. No information about how this
'locked' situation is being resolved, and no information about raid5d
being active in behalf of the (newcomer) RT-process. Any, lower-priority
RT process might have now the ability to permanently block raid5d from
doing it's (higher priority, but unrecognized :) work ..
one might argue that 'if it's doing IO it cannot be seriously RT anymore',
but then again, we had this kswapd argument in the first place ;)
(the argument is not even quite true, just think solid-state disks and
networking, it's well possible to predict latencies (and thus do RT stuff)
there.)
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu