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@xxxxxxxxxxxxxxxxxxxx>
>
> 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@xxxxxxxx>
> Cc: Changli Gao <xiaosuo@xxxxxxxxx>
> Cc: Americo Wang <xiyou.wangcong@xxxxxxxxx>
> Cc: Jiri Slaby <jslaby@xxxxxxx>
> Cc: Eric Dumazet <eric.dumazet@xxxxxxxxx>
> Cc: Mel Gorman <mel@xxxxxxxxx>
> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> ---
>
> 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@xxxxxxxxx>
#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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
