From: ebiederm@xmission.com (Eric W. Biederman)
To: Waiman Long <waiman.long@hp.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Nicolas Dichtel <nicolas.dichtel@6wind.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Alexey Dobriyan <adobriyan@gmail.com>,
linux-kernel@vger.kernel.org,
Scott J Norton <scott.norton@hp.com>,
Douglas Hatch <doug.hatch@hp.com>
Subject: Re: [PATCH] proc: change proc_subdir_lock to a rwlock
Date: Mon, 03 Aug 2015 13:03:20 -0500 [thread overview]
Message-ID: <87wpxcdzbr.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <55BAE31D.6060004@hp.com> (Waiman Long's message of "Thu, 30 Jul 2015 22:53:17 -0400")
Waiman Long <waiman.long@hp.com> writes:
> On 07/30/2015 10:16 PM, Waiman Long wrote:
>> On 07/29/2015 06:21 PM, Eric W. Biederman wrote:
>>> Two quick questions.
>>>
>>> - What motivates this work? Are you seeing lots of
>>> parallel reads on proc?
>>
>> The micro-benchmark that I used was artificial, but it was used to reproduce
>> an exit hanging problem that I saw in real application. In fact, only allow
>> one task to do a lookup seems too limiting to me.
>>> - Why not rcu? Additions and removal of proc generic
>>> files is very rare. Conversion to rcu for reads should
>>> perform better and not take much more work.
>>
>> RCU is harder to verify its correctness, whereas rwlock is easier to use and
>> understand. If it is really a performance critical path where every extra bit
>> of performance counts, I will certainly think RCU may be the right
>> choice. However, in this particular case, I don't think using RCU will give
>> any noticeable performance gain compared with a rwlock.
>
> One more thing, RCU is typically used with linked list. It is not easy to use
> RCU with rbtree and may require major changes to the code.
>
> Another alternative is to use seqlock + RCU, but it will still need more code
> changes than rwlock.
I had forgotten we had switch proc directories to rbtrees. So on that
note.
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Eric
prev parent reply other threads:[~2015-08-03 18:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-29 20:19 [PATCH] proc: change proc_subdir_lock to a rwlock Waiman Long
2015-07-29 22:21 ` Eric W. Biederman
2015-07-30 10:04 ` Alexey Dobriyan
2015-07-31 2:16 ` Waiman Long
2015-07-31 2:53 ` Waiman Long
2015-08-03 18:03 ` Eric W. Biederman [this message]
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=87wpxcdzbr.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=doug.hatch@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolas.dichtel@6wind.com \
--cc=scott.norton@hp.com \
--cc=viro@zeniv.linux.org.uk \
--cc=waiman.long@hp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.