[lkml]   [2007]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 10/10] mm: per device dirty threshold
    On Mon, 23 Apr 2007 08:29:59 +0200 Miklos Szeredi <> wrote:

    > > > What about swapout? That can increase the number of writeback pages,
    > > > without decreasing the number of dirty pages, no?
    > >
    > > Could we not solve that by enabling cap_account_writeback on
    > > swapper_space, and thereby account swap writeback pages. Then the VM
    > > knows it has outstanding IO and need not panic.
    > Hmm, I'm not sure that would be right, because then those writeback
    > pages would be accounted twice: once for swapper_space, and once for
    > the real device.
    > So there's a condition, when lots of anonymous pages are turned into
    > swap-cache writeback pages, and we should somehow throttle this, because
    > >>> This means that all memory is pinned and unreclaimable and the VM gets
    > >>> upset and goes oom.
    > although, it's not quite clear in my mind, how the VM gets upset about
    > this.

    I've been scratching my head on and off for a couple of days over this.

    We've traditionally had reclaim problems when there's a huge amount of
    dirty MAP_SHARED data, which the VM didn't know was dirty. It's the old
    "map a file which is the same size as physical memory and write to it all"

    But we do not have such problems with anonymous memory, and I'm darned if I
    can remember why :(

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-04-23 08:43    [W:0.020 / U:1.364 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site