From: Christoph Lameter <cl@linux.com>
To: akpm@linuxfoundation.org
Cc: rostedt@goodmis.org, linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
linux-mm@kvack.org, penberg@kernel.org, iamjoonsoo@lge.com
Subject: [RFC 0/4] [RFC] slub: Fastpath optimization (especially for RT)
Date: Wed, 22 Oct 2014 10:55:17 -0500 [thread overview]
Message-ID: <20141022155517.560385718@linux.com> (raw)
We had to insert a preempt enable/disable in the fastpath a while ago. This
was mainly due to a lot of state that is kept to be allocating from the per
cpu freelist. In particular the page field is not covered by
this_cpu_cmpxchg used in the fastpath to do the necessary atomic state
change for fast path allocation and freeing.
This patch removes the need for the page field to describe the state of the
per cpu list. The freelist pointer can be used to determine the page struct
address if necessary.
However, currently this does not work for the termination value of a list
which is NULL and the same for all slab pages. If we use a valid pointer
into the page as well as set the last bit then all freelist pointers can
always be used to determine the address of the page struct and we will not
need the page field anymore in the per cpu are for a slab. Testing for the
end of the list is a test if the first bit is set.
So the first patch changes the termination pointer for freelists to do just
that. The second removes the page field and then third can then remove the
preempt enable/disable.
There are currently a number of caveats because we are adding calls to
page_address() and virt_to_head_page() in a number of code paths. These
can hopefully be removed one way or the other.
Removing the ->page field reduces the cache footprint of the fastpath so hopefully overall
allocator effectiveness will increase further. Also RT uses full preemption which means
that currently pretty expensive code has to be inserted into the fastpath. This approach
allows the removal of that code and a corresponding performance increase.
--
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 reply other threads:[~2014-10-22 15:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-22 15:55 Christoph Lameter [this message]
2014-10-22 15:55 ` [RFC 1/4] slub: Remove __slab_alloc code duplication Christoph Lameter
2014-10-22 18:04 ` Thomas Gleixner
2014-10-22 18:27 ` Christoph Lameter
2014-10-22 15:55 ` [RFC 2/4] slub: Use end_token instead of NULL to terminate freelists Christoph Lameter
2014-10-22 15:55 ` [RFC 3/4] slub: Drop ->page field from kmem_cache_cpu Christoph Lameter
2014-10-22 15:55 ` [RFC 4/4] slub: Remove preemption disable/enable from fastpath Christoph Lameter
2014-10-23 8:09 ` [RFC 0/4] [RFC] slub: Fastpath optimization (especially for RT) Joonsoo Kim
2014-10-23 14:18 ` Christoph Lameter
2014-10-24 4:56 ` Joonsoo Kim
2014-10-24 14:02 ` Christoph Lameter
2014-10-27 7:54 ` Joonsoo Kim
2014-10-24 14:41 ` Christoph Lameter
2014-10-27 7:58 ` Joonsoo Kim
2014-10-27 13:53 ` 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=20141022155517.560385718@linux.com \
--to=cl@linux.com \
--cc=akpm@linuxfoundation.org \
--cc=iamjoonsoo@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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).