From: Cyrill Gorcunov <gorcunov@gmail.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Barret Rhoden <brho@google.com>,
Christian Brauner <christian.brauner@ubuntu.com>,
Andrew Morton <akpm@linux-foundation.org>,
Alexey Gladkov <legion@kernel.org>,
William Cohen <wcohen@redhat.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Alexey Dobriyan <adobriyan@gmail.com>,
Chris Hyser <chris.hyser@oracle.com>,
Peter Collingbourne <pcc@google.com>,
Xiaofeng Cao <caoxiaofeng@yulong.com>,
David Hildenbrand <david@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rlimits: do not grab tasklist_lock for do_prlimit on current
Date: Mon, 20 Dec 2021 00:30:10 +0300 [thread overview]
Message-ID: <Yb+kYqLVbL3N9d/4@grain> (raw)
In-Reply-To: <87zgp1psd3.fsf@email.froward.int.ebiederm.org>
On Wed, Dec 15, 2021 at 01:42:32PM -0600, Eric W. Biederman wrote:
...
>
> > If it's too much of a risk/ugliness for not clear enough gain (in code
> > quality or performance), I'm fine with dropping it.
>
> Removing the tasklist_lock where we can is definitely a clear gain.
>
> Simply shoving tasklist_lock aside and making the code more complicated
> is much less clear.
>
> Plus anything you can benchmark (even microbenchmark) and show the
> benefit of is welcome. Especially when you have indications that it
> makes a difference in a larger context.
Thanks for looking into this, Eric! I must confess I've a vague memory
about this code. Still while you're talking about cleanup I wonder if
we should make do_prlimit() being a static function, not global as it
now.
next prev parent reply other threads:[~2021-12-19 21:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-13 22:04 [PATCH] rlimits: do not grab tasklist_lock for do_prlimit on current Barret Rhoden
2021-12-13 22:34 ` Eric W. Biederman
2021-12-15 19:00 ` Barret Rhoden
2021-12-15 19:42 ` Eric W. Biederman
2021-12-19 21:30 ` Cyrill Gorcunov [this message]
2022-01-05 21:31 ` Barret Rhoden
-- strict thread matches above, loose matches on Subject: below --
2021-12-16 20:34 kernel test robot
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=Yb+kYqLVbL3N9d/4@grain \
--to=gorcunov@gmail.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=brho@google.com \
--cc=caoxiaofeng@yulong.com \
--cc=chris.hyser@oracle.com \
--cc=christian.brauner@ubuntu.com \
--cc=david@redhat.com \
--cc=ebiederm@xmission.com \
--cc=legion@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pcc@google.com \
--cc=viresh.kumar@linaro.org \
--cc=wcohen@redhat.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.