lkml.org 
[lkml]   [2007]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC 0/7] Postphone reclaim laundry to write at high water marks
    On Tue, 21 Aug 2007, Peter Zijlstra wrote:

    > It quickly ends up with all of memory in the laundry list and then
    > recursing into __alloc_pages which will fail to make progress and OOMs.

    Hmmmm... Okay that needs to be addressed. Reserves need to be used and we
    only should enter reclaim if that runs out (like the first patch that I
    did).

    > But aside from the numerous issues with the patch set as presented, I'm
    > not seeing the seeing the big picture, why are you doing this.

    I want general improvements to reclaim to address the issues that you see
    and other issues related to reclaim instead of the strange code that makes
    PF_MEMALLOC allocs compete for allocations from a single slab and putting
    logic into the kernel to decide which allocs to fail. We can reclaim after
    all. Its just a matter of finding the right way to do this.

    > Anonymous pages are a there to stay, and we cannot tell people how to
    > use them. So we need some free or freeable pages in order to avoid the
    > vm deadlock that arises from all memory dirty.

    No one is trying to abolish Anonymous pages. Free memory is readily
    available on demand if one calls reclaim. Your scheme introduces complex
    negotiations over a few scraps of memory when large amounts of memory
    would still be readily available if one would do the right thing and call
    into reclaim.

    > 'Optimizing' this by switching to freeable pages has mainly
    > disadvantages IMHO, finding them scrambles LRU order and complexifies
    > relcaim and all that for a relatively small gain in space for clean
    > pagecache pages.

    Sounds like you would like to change the way we handle memory in general
    in the VM? Reclaim (and thus finding freeable pages) is basic to Linux
    memory management.

    > Please, stop writing patches and write down a solid proposal of how you
    > envision the VM working in the various scenarios and why its better than
    > the current approach.

    Sorry I just got into this a short time ago and I may need a few cycles
    to get this all straight. An approach that uses memory instead of
    ignoring available memory is certainly better.
    -
    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: 2007-08-21 23:57    [W:0.029 / U:63.056 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site