From: Christoph Lameter <cl@linux.com>
To: JoonSoo Kim <js1304@gmail.com>
Cc: Pekka Enberg <penberg@kernel.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
David Rientjes <rientjes@google.com>
Subject: Re: [PATCH] slub: try to get cpu partial slab even if we get enough objects for cpu freelist
Date: Wed, 15 Aug 2012 17:32:06 +0000 [thread overview]
Message-ID: <000001392b579d4f-bb5ccaf5-1a2c-472c-9b76-05ec86297706-000000@email.amazonses.com> (raw)
In-Reply-To: <CAAmzW4M9WMnxVKpR00SqufHadY-=i0Jgf8Ktydrw5YXK8VwJ7A@mail.gmail.com>
On Thu, 16 Aug 2012, JoonSoo Kim wrote:
> > Maybe I do not understand you correctly. Could you explain this in some
> > more detail?
>
> I assume that cpu slab and cpu partial slab are not same thing.
>
> In my definition,
> cpu slab is in c->page,
> cpu partial slab is in c->partial
Correct.
> When we have no free objects in cpu slab and cpu partial slab, we try
> to get slab via get_partial_node().
> In that function, we call acquire_slab(). Then we hit "!object" case
> (for cpu slab).
> In that case, we test available with s->cpu_partial.
> I think that s->cpu_partial is for cpu partial slab, not cpu slab.
Ummm... Not entirely. s->cpu_partial is the mininum number of objects to
"cache" per processor. This includes the objects available in the per cpu
slab and the other slabs on the per cpu partial list.
> So this test is not proper.
Ok so this tests occurs in get_partial_node() not in acquire_slab().
If object == NULL then we have so far nothing allocated an c->page ==
NULL. The first allocation refills the cpu_slab (by freezing a slab) so
that we can allocate again. If we go through the loop again then we refill
the per cpu partial lists with more frozen slabs until we have a
sufficient number of objects that we can allocate without obtaining any
locks.
> This patch is for correcting this.
There is nothing wrong with this. The name c->cpu_partial is a bit
awkward. Maybe rename that to c->min_per_cpu_objects or so?
next prev parent reply other threads:[~2012-08-15 17:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-15 15:38 [PATCH] slub: try to get cpu partial slab even if we get enough objects for cpu freelist Joonsoo Kim
2012-08-15 15:45 ` Christoph Lameter
2012-08-15 16:35 ` JoonSoo Kim
2012-08-15 17:32 ` Christoph Lameter [this message]
2012-08-16 13:47 ` JoonSoo Kim
2012-08-16 17:08 ` Christoph Lameter
2012-08-17 13:34 ` JoonSoo Kim
2012-08-17 14:02 ` Christoph Lameter
2012-08-17 14:37 ` JoonSoo Kim
2012-08-17 14:56 ` 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=000001392b579d4f-bb5ccaf5-1a2c-472c-9b76-05ec86297706-000000@email.amazonses.com \
--to=cl@linux.com \
--cc=js1304@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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;
as well as URLs for NNTP newsgroup(s).