lkml.org 
[lkml]   [2007]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: The performance and behaviour of the anti-fragmentation related patches
    On Fri, 02 Mar 2007 12:43:42 -0500 Rik van Riel <riel@redhat.com> wrote:
    >> I can't share all the details, since a lot of the problems are customer
    >> workloads.
    >> One particular case is a 32GB system with a database that takes most
    >> of memory. The amount of actually freeable page cache memory is in
    >> the hundreds of MB.

    On Fri, Mar 02, 2007 at 10:06:19AM -0800, Andrew Morton wrote:
    > Where's the rest of the memory? tmpfs? mlocked? hugetlb?

    I know of one sounding similar to this where unreclaimable pages are
    pinned by refcounts held by bio's spread across about 850 spindles.
    It's mostly read traffic. Several different tunables could be used
    to work around it, nr_requests in particular, but also clamping down
    on dirty limits to preposterously low levels and setting preposterously
    large values of min_free_kbytes. Their kernel is, of course,
    substantially downrev (2.6.9-based IIRC), so douse things heavily with
    grains of salt.


    -- wli
    -
    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-03-02 22:03    [W:6.379 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site