[EMAIL PROTECTED] (Linus Torvalds) writes:
>
> Somebody interested in trying the above add? And looking for other more
> obvious bandaid fixes. It won't "fix" swapoff per se, but it might make
> it bearable and bring it to the 2.2.x levels.
At little bit. The one really bad behavior of not letting any other
processes run seems to be fixed with an explicit:
if (need_resched) {
schedule();
}
What I can't figure out is why this is necessary. Because we should
be sleeping in alloc_pages if nowhere else.
I suppose if the bulk of our effort really is freeing dead swap cache
pages we can spin without sleeping, and never let another process run
because we are busily recycling dead swap cache pages. Does this sound
right?
If this is going on I think we need to look at our delayed
deallocation policy a little more carefully. I suspect we should
have code in kswapd actively removing these dead swap cache pages.
After we get the latency improvements in exit these pages do
absolutely nothing for us except clog up the whole system, and
generally give the 2.4 VM a bad name.
Anyone care to check my analysis?
> Is anybody interested in making "swapoff()" better? Please speak up..
Interested. But finding the time...
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
