From: Christoph Lameter <clameter@sgi.com>
To: linux-kernel@vger.kernel.org
Cc: "Paul E. McKenney" <paulmck@us.ibm.com>,
Jens Axboe <axboe@suse.de>, Dave Miller <davem@redhat.com>,
Hugh Dickins <hugh@veritas.com>,
linux-mm@kvack.org, Christoph Lameter <clameter@sgi.com>,
Ingo Molnar <mingo@elte.hu>
Subject: [PATCH 0/4] struct file RCU optimizations V2
Date: Thu, 22 Jun 2006 14:31:02 -0700 (PDT) [thread overview]
Message-ID: <20060622213102.32391.19996.sendpatchset@schroedinger.engr.sgi.com> (raw)
Optimize RCU handling for struct file by relying on slab RCU handling
(Thanks for all the feedback on the RFC for this....)
Currently we schedule RCU frees for each file we free separately. That has
several drawbacks against the earlier file handling (in 2.6.5 f.e.), which
did not require RCU callbacks:
1. Excessive number of RCU callbacks can be generated causing long RCU
queues that in turn cause long latencies.
2. The cache hot object is not preserved between free and realloc. A close
followed by another open is very fast with the RCUless approach because
the last freed object is returned by the slab allocator that is
still cache hot. RCU free means that the object is not immediately
available again. The new object is cache cold and therefore open/close
performance tests show a significant degradation with the RCU
implementation.
One solution to this problem is to move the RCU freeing into the Slab
allocator by specifying SLAB_DESTROY_BY_RCU as an option at slab creation
time. The slab allocator will do RCU frees only when it is necessary
to dispose of slabs of objects (rare). So with that approach we can cut
out the RCU overhead significantly.
However, the slab allocator may return the object for another use even
before the RCU period has expired under SLAB_DESTROY_BY_RCU. This means
there is the (unlikely) possibility that the object is going to be
switched under us in sections protected by rcu_read_lock() and
rcu_read_unlock(). So we need to verify that we have acquired the correct
object after establishing a stable object reference (incrementing the
refcounter does that).
I have tested this on IA64 NUMA with aim7.
Patch was first discussed at:
http://marc.theaimsgroup.com/?t=115048747200002&r=1&w=2
V1->V2:
- Consolidate common code after finding fget in fget_light.
- Rename fu_list to its prior name f_list.
- Do not clear variables in get_empty_filp() that are cleared
later by other subsystems.
- Move the eventpoll initialization into the constructor.
- Split up the patch into patchset of 4 patches.
The patchset consists of 4 patches against 2.6.17 that are following
this message.
--
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:[~2006-06-22 21:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-22 21:31 Christoph Lameter [this message]
2006-06-22 21:31 ` [PATCH 1/4] Create files_init_early() Christoph Lameter
2006-06-22 21:31 ` [PATCH 2/4] Remove duplication of fget() Christoph Lameter
2006-06-22 21:31 ` [PATCH 3/4] Use SLAB_DESTROY_BY_RCU Christoph Lameter
2006-06-22 21:31 ` [PATCH 4/4] Drop rcu field 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=20060622213102.32391.19996.sendpatchset@schroedinger.engr.sgi.com \
--to=clameter@sgi.com \
--cc=axboe@suse.de \
--cc=davem@redhat.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=paulmck@us.ibm.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