From: Christoph Lameter <cl@linux.com>
To: Glauber Costa <glommer@parallels.com>
Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
Johannes Weiner <hannes@cmpxchg.org>,
Mel Gorman <mgorman@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Shrinnker <david@fromorbit.com>,
Michal Hocko <mhocko@suse.cz>,
kamezawa.hiroyu@jp.fujitsu.com, Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Pekka Enberg <penberg@cs.helsinki.fi>
Subject: Re: [PATCH 3/3] sl[auo]b: retry allocation once in case of failure.
Date: Wed, 2 Jan 2013 16:10:21 +0000 [thread overview]
Message-ID: <0000013bfc071798-e09146e7-8c3c-41be-a700-1676fd418e59-000000@email.amazonses.com> (raw)
In-Reply-To: <1355925702-7537-4-git-send-email-glommer@parallels.com>
On Wed, 19 Dec 2012, Glauber Costa wrote:
> When we are out of space in the caches, we will try to allocate a new
> page. If we still fail, the page allocator will try to free pages
> through direct reclaim. Which means that if an object allocation failed
> we can be sure that no new pages could be given to us, even though
> direct reclaim was likely invoked.
Well this hits the hot allocation path with lots of additional checks
that also require the touching of more cachelines.
How much impact will this have?
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2013-01-02 16:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-19 14:01 [PATCH 0/3] retry slab allocation after first failure Glauber Costa
2012-12-19 14:01 ` [PATCH 1/3] slab: single entry-point for slab allocation Glauber Costa
2012-12-19 14:01 ` [PATCH 2/3] slub: remove slab_alloc wrapper Glauber Costa
2013-01-02 16:03 ` Christoph Lameter
2012-12-19 14:01 ` [PATCH 3/3] sl[auo]b: retry allocation once in case of failure Glauber Costa
2012-12-26 2:16 ` Kamezawa Hiroyuki
2012-12-26 7:55 ` Glauber Costa
2013-01-02 16:10 ` Christoph Lameter [this message]
2013-01-09 10:25 ` Glauber Costa
2013-01-02 16:32 ` [PATCH 0/3] retry slab allocation after first failure Christoph Lameter
2013-01-09 10:22 ` Glauber Costa
2013-01-09 15:38 ` Christoph Lameter
2013-01-09 15:59 ` Glauber Costa
2013-01-09 18:59 ` Christoph Lameter
2013-01-02 16:33 ` Christoph Lameter
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=0000013bfc071798-e09146e7-8c3c-41be-a700-1676fd418e59-000000@email.amazonses.com \
--to=cl@linux.com \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=glommer@parallels.com \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--cc=penberg@cs.helsinki.fi \
--cc=penberg@kernel.org \
--cc=rientjes@google.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