lkml.org 
[lkml]   [2011]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Regression from 2.6.36
    From
    Date
    Le mercredi 13 avril 2011 à 14:16 -0700, Andrew Morton a écrit :

    > So am I correct in believing that this regression is due to the
    > high-order allocations putting excess stress onto page reclaim?
    >

    I suppose so.

    > If so, then how large _are_ these allocations? This perhaps can be
    > determined from /proc/slabinfo. They must be pretty huge, because slub
    > likes to do excessively-large allocations and the system handles that
    > reasonably well.
    >
    > I suppose that a suitable fix would be
    >
    >
    > From: Andrew Morton <akpm@linux-foundation.org>
    >
    > Azurit reports large increases in system time after 2.6.36 when running
    > Apache. It was bisected down to a892e2d7dcdfa6c76e6 ("vfs: use kmalloc()
    > to allocate fdmem if possible").
    >
    > That patch caused the vfs to use kmalloc() for very large allocations and
    > this is causing excessive work (and presumably excessive reclaim) within
    > the page allocator.
    >
    > Fix it by falling back to vmalloc() earlier - when the allocation attempt
    > would have been considered "costly" by reclaim.
    >
    > Reported-by: azurIt <azurit@pobox.sk>
    > Cc: Changli Gao <xiaosuo@gmail.com>
    > Cc: Americo Wang <xiyou.wangcong@gmail.com>
    > Cc: Jiri Slaby <jslaby@suse.cz>
    > Cc: Eric Dumazet <eric.dumazet@gmail.com>
    > Cc: Mel Gorman <mel@csn.ul.ie>
    > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    > ---
    >
    > fs/file.c | 17 ++++++++++-------
    > 1 file changed, 10 insertions(+), 7 deletions(-)
    >
    > diff -puN fs/file.c~a fs/file.c
    > --- a/fs/file.c~a
    > +++ a/fs/file.c
    > @@ -39,14 +39,17 @@ int sysctl_nr_open_max = 1024 * 1024; /*
    > */
    > static DEFINE_PER_CPU(struct fdtable_defer, fdtable_defer_list);
    >
    > -static inline void *alloc_fdmem(unsigned int size)
    > +static void *alloc_fdmem(unsigned int size)
    > {
    > - void *data;
    > -
    > - data = kmalloc(size, GFP_KERNEL|__GFP_NOWARN);
    > - if (data != NULL)
    > - return data;
    > -
    > + /*
    > + * Very large allocations can stress page reclaim, so fall back to
    > + * vmalloc() if the allocation size will be considered "large" by the VM.
    > + */
    > + if (size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER) {
    > + void *data = kmalloc(size, GFP_KERNEL|__GFP_NOWARN);
    > + if (data != NULL)
    > + return data;
    > + }
    > return vmalloc(size);
    > }
    >
    > _
    >

    Acked-by: Eric Dumazet <eric.dumazet@gmail.com>

    #define PAGE_ALLOC_COSTLY_ORDER 3

    On x86_64, this means we try kmalloc() up to 4096 files in fdtable.

    Thanks !


    --
    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: 2011-04-14 04:13    [W:4.019 / U:1.412 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site