| | Subject | Re: Break 2.4 VM in five easy steps | | From | (Eric W. Biederman) | | Date | 07 Jun 2001 01:42:06 -0600 |
| |
torvalds@transmeta.com (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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|