Messages in this thread | | | From | Al Boldi <> | Subject | Re: [PATCH] strict VM overcommit accounting for 2.4.32/2.4.33-pre1 | Date | Sat, 31 Dec 2005 20:36:01 +0300 |
| |
Arjan van de Ven wrote: > On Sat, 2005-12-31 at 17:02 +0300, Al Boldi wrote: > > Shouldn't it be possible to disable overcommit completely, thus giving > > kswapd a break from running wild trying to find something to swap/page, > > which is the reason why the system gets unstable going over 95% in your > > example. > > shared mappings make this impractical. To disable overcommit completely, > each process would need to account for all its own shared libraries, eg > each process gets glibc added etc. You'll find that on any > non-extremely-stripped system you then end up with much more memory > needed than you have ram.
Are you implying shared maps are implemented by way of overcommitting?
Really, overcommit is an add-on feature like swapping, only overcommit is free because it's a lier. So removing an add-on feature should not affect the underlying system in any way, such as shared mappings or swapping.
It should be possible to allow swapping to handle all memory requests exceeding physical RAM. OverCommit should be a tuning option for those who like to live on the edge, because it really is a gamble.
In the case where swap = physical RAM and overcommit_ratio = 0, the kernel is in effect hiding the fact that it is overcommitting.
Can you see the overhead involved here?
Thanks for your input!
-- Al
- 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/
| |