[lkml]   [2005]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH 0/8] Critical Page Pool
    Pavel Machek wrote:
    > On Fri 18-11-05 11:32:57, Matthew Dobson wrote:
    >>We have a clustering product that needs to be able to guarantee that the
    >>networking system won't stop functioning in the case of OOM/low memory
    >>condition. The current mempool system is inadequate because to keep the
    >>whole networking stack functioning, we need more than 1 or 2 slab caches to
    >>be guaranteed. We need to guarantee that any request made with a specific
    >>flag will succeed, assuming of course that you've made your "critical page
    >>pool" big enough.
    >>The following patch series implements such a critical page pool. It
    >>creates 2 userspace triggers:
    >>/proc/sys/vm/critical_pages: write the number of pages you want to reserve
    >>for the critical pool into this file
    >>/proc/sys/vm/in_emergency: write a non-zero value to tell the kernel that
    >>the system is in an emergency state and authorize the kernel to dip into
    >>the critical pool to satisfy critical allocations.
    >>We mark critical allocations with the __GFP_CRITICAL flag, and when the
    >>system is in an emergency state, we are allowed to delve into this pool to
    >>satisfy __GFP_CRITICAL allocations that cannot be satisfied through the
    >>normal means.
    > Ugh, relying on userspace to tell you that you need to dip into emergency
    > pool seems to be racy and unreliable. How can you guarantee that userspace
    > is scheduled soon enough in case of OOM?
    > Pavel

    It's not really for userspace to tell us that we're about to OOM, as the
    kernel is in a far better position to determine that. It is to let the
    kernel know that *something* has gone wrong, and we've got to keep
    networking (or any other user of __GFP_CRITICAL) up for a few minutes, *no
    matter what*. We may not ever OOM, or even run terribly low on memory, but
    the trigger allows the use of the pool IF that happens.

    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: 2005-11-21 07:00    [W:0.023 / U:49.924 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site