No. kswapd should NOT be real-time. It should not have been real-time in
the first place.
The thing is, that if we have a _real_ real-time process running (that
doesn't need any more memory), then kswapd does _not_ have the right to
take over. That in itself is proof that kswapd must never be real-time.
If a realtime process needs memory, the kernel does have a back-door to
let kswapd run: when we really run out of memory __get_free_pages() will
do the right thing even if the caller has real-time priority.
> I wouldn't call this 'carefully' at all. The reason
> we do multiple tries in kswapd is because we _can't_
> give up on the first failure. The rest of the system
> relies on us!
Nope, it doesn't "rely" on kswapd at all. __get_free_pages() will try to
page stuff out, and in addition the timer tick will re-start kswapd for
the cases where we use a lot of GFP_ATOMIC and cannot page out.
The _only_ thing kswapd is good for is to "even out" the peaks, so that
when processes need memory they normally don't have to free anything
themselves. Essentially, kswapd should be seen as a idle deamon that tries
to make memory available in the background (arguing very strongly against
kswapd ever being considered real-time).
Look at the patch that I sent out earlier: it really enforces this.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/