lkml.org 
[lkml]   [2011]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH 2/3] mm: slub: Do not take expensive steps for SLUBs speculative high-order allocations
    Date
    To avoid locking and per-cpu overhead, SLUB optimisically uses
    high-order allocations and falls back to lower allocations if they
    fail. However, by simply trying to allocate, the caller can enter
    compaction or reclaim - both of which are likely to cost more than the
    benefit of using high-order pages in SLUB. On a desktop system, two
    users report that the system is getting stalled with kswapd using large
    amounts of CPU.

    This patch prevents SLUB taking any expensive steps when trying to
    use high-order allocations. Instead, it is expected to fall back to
    smaller orders more aggressively. Testing from users was somewhat
    inconclusive on how much this helped but local tests showed it made
    a positive difference. It makes sense that falling back to order-0
    allocations is faster than entering compaction or direct reclaim.

    Signed-off-yet: Mel Gorman <mgorman@suse.de>
    ---
    mm/page_alloc.c | 3 ++-
    mm/slub.c | 3 ++-
    2 files changed, 4 insertions(+), 2 deletions(-)

    diff --git a/mm/page_alloc.c b/mm/page_alloc.c
    index 9f8a97b..057f1e2 100644
    --- a/mm/page_alloc.c
    +++ b/mm/page_alloc.c
    @@ -1972,6 +1972,7 @@ gfp_to_alloc_flags(gfp_t gfp_mask)
    {
    int alloc_flags = ALLOC_WMARK_MIN | ALLOC_CPUSET;
    const gfp_t wait = gfp_mask & __GFP_WAIT;
    + const gfp_t can_wake_kswapd = !(gfp_mask & __GFP_NO_KSWAPD);

    /* __GFP_HIGH is assumed to be the same as ALLOC_HIGH to save a branch. */
    BUILD_BUG_ON(__GFP_HIGH != (__force gfp_t) ALLOC_HIGH);
    @@ -1984,7 +1985,7 @@ gfp_to_alloc_flags(gfp_t gfp_mask)
    */
    alloc_flags |= (__force int) (gfp_mask & __GFP_HIGH);

    - if (!wait) {
    + if (!wait && can_wake_kswapd) {
    /*
    * Not worth trying to allocate harder for
    * __GFP_NOMEMALLOC even if it can't schedule.
    diff --git a/mm/slub.c b/mm/slub.c
    index 98c358d..1071723 100644
    --- a/mm/slub.c
    +++ b/mm/slub.c
    @@ -1170,7 +1170,8 @@ static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int node)
    * Let the initial higher-order allocation fail under memory pressure
    * so we fall-back to the minimum order allocation.
    */
    - alloc_gfp = (flags | __GFP_NOWARN | __GFP_NORETRY | __GFP_NO_KSWAPD) & ~__GFP_NOFAIL;
    + alloc_gfp = (flags | __GFP_NOWARN | __GFP_NORETRY | __GFP_NO_KSWAPD) &
    + ~(__GFP_NOFAIL | __GFP_WAIT);

    page = alloc_slab_page(alloc_gfp, node, oo);
    if (unlikely(!page)) {
    --
    1.7.3.4


    \
     
     \ /
      Last update: 2011-05-11 17:51    [W:0.021 / U:30.364 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site