From: Eric Dumazet <eric.dumazet@gmail.com>
To: Christoph Lameter <cl@linux.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
Mel Gorman <mgorman@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
Colin King <colin.king@canonical.com>,
Raghavendra D Prabhu <raghu.prabhu13@gmail.com>,
Jan Kara <jack@suse.cz>, Chris Mason <chris.mason@oracle.com>,
Pekka Enberg <penberg@kernel.org>, Rik van Riel <riel@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 3/3] mm: slub: Default slub_max_order to 0
Date: Thu, 12 May 2011 18:10:38 +0200 [thread overview]
Message-ID: <1305216638.3795.36.camel@edumazet-laptop> (raw)
In-Reply-To: <alpine.DEB.2.00.1105121050220.26013@router.home>
Le jeudi 12 mai 2011 A 11:01 -0500, Christoph Lameter a A(C)crit :
> On Thu, 12 May 2011, James Bottomley wrote:
>
> > > Debian and Ubuntu have been using SLUB for a long time
> >
> > Only from Squeeze, which has been released for ~3 months. That doesn't
> > qualify as a "long time" in my book.
>
> I am sorry but I have never used a Debian/Ubuntu system in the last 3
> years that did not use SLUB. And it was that by default. But then we
> usually do not run the "released" Debian version. Typically one runs
> testing. Ubuntu is different there we usually run releases. But those
> have been SLUB for as long as I remember.
>
> And so far it is rock solid and is widely rolled out throughout our
> infrastructure (mostly 2.6.32 kernels).
>
> > but a sample of one doeth not great testing make.
> >
> > However, since you admit even you see problems, let's concentrate on
> > fixing them rather than recriminations?
>
> I do not see problems here with earlier kernels. I only see these on one
> testing system with the latest kernels on Ubuntu 11.04.
More fuel to this discussion with commit 6d4831c2
Something is wrong with high order allocations, on some machines.
Maybe we can find real cause instead of limiting us to use order-0 pages
in the end... ;)
commit 6d4831c283530a5f2c6bd8172c13efa236eb149d
Author: Andrew Morton <akpm@linux-foundation.org>
Date: Wed Apr 27 15:26:41 2011 -0700
vfs: avoid large kmalloc()s for the fdtable
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.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-05-12 16:10 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-11 15:29 [PATCH 0/3] Reduce impact to overall system of SLUB using high-order allocations Mel Gorman
2011-05-11 15:29 ` [PATCH 1/3] mm: slub: Do not wake kswapd for SLUBs speculative " Mel Gorman
2011-05-11 20:38 ` David Rientjes
2011-05-11 15:29 ` [PATCH 2/3] mm: slub: Do not take expensive steps " Mel Gorman
2011-05-11 20:38 ` David Rientjes
2011-05-11 21:10 ` Mel Gorman
2011-05-12 17:25 ` Andrea Arcangeli
2011-05-11 15:29 ` [PATCH 3/3] mm: slub: Default slub_max_order to 0 Mel Gorman
2011-05-11 20:38 ` David Rientjes
2011-05-11 20:53 ` James Bottomley
2011-05-11 21:09 ` Mel Gorman
2011-05-11 22:27 ` David Rientjes
2011-05-13 10:14 ` Mel Gorman
2011-05-12 17:36 ` Andrea Arcangeli
2011-05-16 21:03 ` David Rientjes
2011-05-17 9:48 ` Mel Gorman
2011-05-17 19:25 ` David Rientjes
2011-05-12 14:43 ` Christoph Lameter
2011-05-12 15:15 ` James Bottomley
2011-05-12 15:27 ` Christoph Lameter
2011-05-12 15:43 ` James Bottomley
2011-05-12 15:46 ` Dave Jones
2011-05-12 16:00 ` James Bottomley
2011-05-12 16:08 ` Dave Jones
2011-05-12 16:27 ` Christoph Lameter
2011-05-12 16:30 ` James Bottomley
2011-05-12 16:48 ` Christoph Lameter
2011-05-12 17:46 ` Andrea Arcangeli
2011-05-12 18:00 ` Christoph Lameter
2011-05-12 18:18 ` Andrea Arcangeli
2011-05-12 17:06 ` Pekka Enberg
2011-05-12 17:11 ` Pekka Enberg
2011-05-12 17:38 ` Christoph Lameter
2011-05-12 18:00 ` Andrea Arcangeli
2011-05-13 9:49 ` Mel Gorman
2011-05-15 16:39 ` Andrea Arcangeli
2011-05-16 8:42 ` Mel Gorman
2011-05-12 17:51 ` Andrea Arcangeli
2011-05-12 18:03 ` Christoph Lameter
2011-05-12 18:09 ` Andrea Arcangeli
2011-05-12 18:16 ` Christoph Lameter
2011-05-12 18:36 ` James Bottomley
2011-05-12 17:40 ` Andrea Arcangeli
2011-05-12 15:55 ` Pekka Enberg
2011-05-12 18:37 ` James Bottomley
2011-05-12 18:46 ` Christoph Lameter
2011-05-12 19:21 ` James Bottomley
2011-05-12 19:44 ` James Bottomley
2011-05-12 20:04 ` James Bottomley
2011-05-12 20:29 ` Johannes Weiner
2011-05-12 20:31 ` Johannes Weiner
2011-05-12 20:31 ` James Bottomley
2011-05-12 22:04 ` James Bottomley
2011-05-12 22:15 ` Johannes Weiner
2011-05-12 22:58 ` Minchan Kim
2011-05-13 5:39 ` Minchan Kim
2011-05-13 0:47 ` James Bottomley
2011-05-13 4:12 ` James Bottomley
2011-05-13 10:55 ` Mel Gorman
2011-05-13 14:16 ` James Bottomley
2011-05-13 10:30 ` Mel Gorman
2011-05-13 6:16 ` Pekka Enberg
2011-05-13 10:05 ` Mel Gorman
2011-05-12 16:01 ` Christoph Lameter
2011-05-12 16:10 ` Eric Dumazet [this message]
2011-05-12 17:37 ` Andrew Morton
2011-05-12 15:45 ` Dave Jones
2011-05-11 21:39 ` [PATCH 0/3] Reduce impact to overall system of SLUB using high-order allocations James Bottomley
2011-05-11 22:28 ` David Rientjes
2011-05-11 22:34 ` James Bottomley
2011-05-12 11:13 ` Pekka Enberg
2011-05-12 13:19 ` Mel Gorman
2011-05-12 14:04 ` James Bottomley
2011-05-12 15:53 ` James Bottomley
2011-05-13 11:25 ` Mel Gorman
2011-05-12 18:04 ` Andrea Arcangeli
2011-05-13 11:24 ` Mel Gorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1305216638.3795.36.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@linux-foundation.org \
--cc=chris.mason@oracle.com \
--cc=cl@linux.com \
--cc=colin.king@canonical.com \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=penberg@kernel.org \
--cc=raghu.prabhu13@gmail.com \
--cc=riel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox