[lkml]   [2007]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/5] make slab gfp fair
    On Thu, 17 May 2007, Matt Mackall wrote:

    > Simply stated, the problem is sometimes it's impossible to free memory
    > without allocating more memory. Thus we must keep enough protected
    > reserve that we can guarantee progress. This is what mempools are for
    > in the regular I/O stack. Unfortunately, mempools are a bad match for
    > network I/O.
    > It's absolutely correct that performance doesn't matter in the case
    > this patch is addressing. All that matters is digging ourselves out of
    > OOM. The box either survives the crisis or it doesn't.

    Well we fail allocations in order to do so and these allocations may be
    even nonatomic allocs. Pretty dangerous approach.

    > It's also correct that we should hardly ever get into a situation
    > where we trigger this problem. But such cases are still fairly easy to
    > trigger in some workloads. Swap over network is an excellent example,
    > because we typically don't start swapping heavily until we're quite
    > low on freeable memory.

    Is it not possible to avoid failing allocs? Instead put processes to
    sleep? Run synchrononous reclaim?

    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-05-17 20:05    [W:0.021 / U:153.868 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site