lkml.org 
[lkml]   [2007]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [00/41] Large Blocksize Support V7 (adds memmap support)
    Date
    On Thursday 13 September 2007 09:06, Christoph Lameter wrote:
    > On Wed, 12 Sep 2007, Nick Piggin wrote:

    > > So lumpy reclaim does not change my formula nor significantly help
    > > against a fragmentation attack. AFAIKS.
    >
    > Lumpy reclaim improves the situation significantly because the
    > overwhelming majority of allocation during the lifetime of a systems are
    > movable and thus it is able to opportunistically restore the availability
    > of higher order pages by reclaiming neighboring pages.

    I'm talking about non movable allocations.


    > > [*] ok, this isn't quite true because if you can actually put a hard
    > > limit on unmovable allocations then anti-frag will fundamentally help --
    > > get back to me on that when you get patches to move most of the obvious
    > > ones.
    >
    > We have this hard limit using ZONE_MOVABLE in 2.6.23.

    So we're back to 2nd class support.


    > > Sure, and I pointed out the theoretical figure for 64K pages as well. Is
    > > that figure not problematic to you? Where do you draw the limit for what
    > > is acceptable? Why? What happens with tiny memory machines where a
    > > reserve or even the anti-frag patches may not be acceptable and/or work
    > > very well? When do you require reserve pools? Why are reserve pools
    > > acceptable for first-class support of filesystems when it has been very
    > > loudly been made a known policy decision by Linus in the past (and for
    > > some valid reasons) that we should not put limits on the sizes of caches
    > > in the kernel.
    >
    > 64K pages may problematic because it is above the PAGE_ORDER_COSTLY in
    > 2.6.23. 32K is currently much safer because lumpy reclaim can restore
    > these and does so on my systems. I expect the situation for 64K pages to
    > improve when more of Mel's patches go in. We have long term experience
    > with 32k sized allocation through Andrew's tree.
    >
    > Reserve pools as handled (by the not yet available) large page pool
    > patches (which again has altogether another purpose) are not a limit. The
    > reserve pools are used to provide a mininum of higher order pages that is
    > not broken down in order to insure that a mininum number of the desired
    > order of pages is even available in your worst case scenario. Mainly I
    > think that is needed during the period when memory defragmentation is
    > still under development.

    fsblock doesn't need any of those hacks, of course.
    -
    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-09-14 14:47    [W:0.034 / U:1.132 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site