lkml.org 
[lkml]   [2006]   [Jan]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] strict VM overcommit accounting for 2.4.32/2.4.33-pre1
From
Date
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/

\
 
 \ /
  Last update: 2006-01-01 10:17    [W:0.048 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site