Messages in this thread | | | Date | Sun, 25 Oct 1998 14:28:28 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [patch] my latest oom stuff |
| |
On Sun, 25 Oct 1998, Rik van Riel wrote: > > This effectively removes realtime priority from kswapd > -- this is plain wrong because we need to rely on kswapd > even in triple-digit loads...
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/
| |