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.026 / U:30.200 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site