linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Feng Tang <feng.tang@intel.com>, Oleg Nesterov <oleg@redhat.com>,
	Jiri Olsa <jolsa@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	kernel test robot <rong.a.chen@intel.com>,
	Ingo Molnar <mingo@kernel.org>,
	Vince Weaver <vincent.weaver@maine.edu>,
	Jiri Olsa <jolsa@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>,
	Ravi Bangoria <ravi.bangoria@linux.ibm.com>,
	Stephane Eranian <eranian@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	lkp@lists.01.org, andi.kleen@intel.com, "Huang,
	Ying" <ying.huang@intel.com>
Subject: Re: [LKP] Re: [perf/x86] 81ec3f3c4c: will-it-scale.per_process_ops -5.5% regression
Date: Mon, 24 Feb 2020 13:43:02 -0800	[thread overview]
Message-ID: <CAHk-=wh0z0LErNzwe-AqrEkv3BNzJep58Qmi2dM775UPtmq0og@mail.gmail.com> (raw)
In-Reply-To: <87a757znqd.fsf@x220.int.ebiederm.org>

On Mon, Feb 24, 2020 at 1:22 PM Eric W. Biederman <ebiederm@xmission.com> wrote:
>
> I keep looking at your patch and wondering if there isn't a way
> to remove the uid refcount entirely on this path.

I agree. I tried to come up with something, but couldn't.

> Linus I might be wrong but I have this sense that your change will only
> help when signal delivery is backed up.  I expect in the common case
> there won't be any pending signals outstanding for the user.

Again, 100% agreed.

HOWEVER.

The normal case where there's one only signal pending is also the case
where we don't care about the extra atomic RMW access. By definition
that's not going to ever going to show up as a performance issue or
for cacheline contention.

So the only case that matters from a performance standpoint is the
"lots of signals" case, in which case you'll see that sigqueue become
backed up.

But as I said in the original thread (before you got added to the list):

 "I don't know. This does not seem to be a particularly serious load."

I'm not convinced this will show up outside of this kind of
signal-sending microbenchmark.

That said, I don't really see any downside to the patch either, so...

                Linus

  reply	other threads:[~2020-02-24 21:50 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-05 12:32 [perf/x86] 81ec3f3c4c: will-it-scale.per_process_ops -5.5% regression kernel test robot
2020-02-05 12:58 ` Peter Zijlstra
2020-02-06  3:04   ` [LKP] " Li, Philip
2020-02-21  8:03   ` Feng Tang
2020-02-21 10:58     ` Peter Zijlstra
2020-02-21 13:20     ` Jiri Olsa
2020-02-23 14:11       ` Feng Tang
2020-02-23 17:37         ` Linus Torvalds
2020-02-24  0:33           ` Feng Tang
2020-02-24  1:06             ` Linus Torvalds
2020-02-24  1:58               ` Huang, Ying
2020-02-24  2:19               ` Feng Tang
2020-02-24 13:20                 ` Feng Tang
2020-02-24 19:24                 ` Linus Torvalds
2020-02-24 19:42                   ` Kleen, Andi
2020-02-24 20:09                   ` Linus Torvalds
2020-02-24 20:47                     ` Linus Torvalds
2020-02-24 21:20                       ` Eric W. Biederman
2020-02-24 21:43                         ` Linus Torvalds [this message]
2020-02-24 21:59                           ` Eric W. Biederman
2020-02-24 22:12                             ` Linus Torvalds
2020-02-25  2:57                       ` Feng Tang
2020-02-25  3:15                         ` Linus Torvalds
2020-02-25  4:53                           ` Feng Tang
2020-02-23 19:36         ` Jiri Olsa
2020-02-21 18:05     ` Kleen, Andi
2020-02-22 12:43       ` Feng Tang
2020-02-22 17:08         ` Kleen, Andi

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='CAHk-=wh0z0LErNzwe-AqrEkv3BNzJep58Qmi2dM775UPtmq0og@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=acme@kernel.org \
    --cc=acme@redhat.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andi.kleen@intel.com \
    --cc=ebiederm@xmission.com \
    --cc=eranian@google.com \
    --cc=feng.tang@intel.com \
    --cc=jolsa@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@lists.01.org \
    --cc=mingo@kernel.org \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=ravi.bangoria@linux.ibm.com \
    --cc=rong.a.chen@intel.com \
    --cc=tglx@linutronix.de \
    --cc=vincent.weaver@maine.edu \
    --cc=ying.huang@intel.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).