Messages in this thread | | | Subject | Re: [PATCH] strict VM overcommit accounting for 2.4.32/2.4.33-pre1 | From | Arjan van de Ven <> | Date | Sun, 01 Jan 2006 10:12:33 +0100 |
| |
On Sat, 2005-12-31 at 20:36 +0300, Al Boldi wrote: > 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?
yes. Using only 1 page shared is already overcommitting because in principle each user can cause a COW on that page and cause a memory allocation for it in the future. (just like "traditional" overcommit can cause a pagefault with an allocation)
> 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.
then I think you're misunderstanding how the linux VM works
> 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.
but it's a worthwhile gamble to not need GOBBLES of memory you're not using 99.9999999999999% of the time
> > In the case where swap = physical RAM and overcommit_ratio = 0, the kernel is > in effect hiding the fact that it is overcommitting.
swap==ram is not really relevant; you'll need a LOT more to cover the shared maps...
- 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/
| |