mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Bae, Chang Seok" <chang.seok.bae@intel.com>
To: "Hansen, Dave" <dave.hansen@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>
Cc: "Sang, Oliver" <oliver.sang@intel.com>,
	Borislav Petkov <bp@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	"lkp@lists.01.org" <lkp@lists.01.org>, lkp <lkp@intel.com>,
	"Huang, Ying" <ying.huang@intel.com>,
	"Tang, Feng" <feng.tang@intel.com>,
	"zhengjun.xing@linux.intel.com" <zhengjun.xing@linux.intel.com>,
	"Yin, Fengwei" <fengwei.yin@intel.com>
Subject: Re: [x86/signal] 3aac3ebea0: will-it-scale.per_thread_ops -11.9% regression
Date: Wed, 8 Dec 2021 18:00:06 +0000	[thread overview]
Message-ID: <DF832BC5-AB0F-44AD-83C3-E0108176F945@intel.com> (raw)
In-Reply-To: <bbc24579-b6ee-37cb-4bbf-10e3476537e0@intel.com>

On Dec 7, 2021, at 15:14, Hansen, Dave <dave.hansen@intel.com> wrote:
> 
> Oliver or Chang, could you try to reproduce this by hand on one of the
> suspect systems?  Build:
> 
>  1bdda24c4a ("signal: Add an optional check for altstack size")
> 
> then run will-it-scale by hand.  Then build:
> 
>  3aac3ebea0 ("x86/signal: Implement sigaltstack size validation")
> 
> and run it again.  Also, do we see any higher core-count regressions?
> These all seem to happen with:
> 
> 	mode=thread
> 	nr_task=16
> 
> That's really odd to see that for these systems with probably ~50 cores
> each.  I'd expect to see it get worse at higher core counts.

tglx also asked a similar thing -- test it without the python script between
5.16-rcX vs 5.15.

So, ran this with those kernel versions and some patches:
    $ ./signal1_threads -s 10 -t 16

The test accounts total number of delivered signals in 16 threads in a second.
Repeat this 10 times and then average out. That’s what '{ average }' tells. So,
higher is better.

In this test, the lock contention came from this signal return path:
    rt_sigreturn()
        --> restore_altstack()
            --> do_sigaltstack()
But do_sigaltstack() is not needed here as no sigaltstack changes. So, perhaps
skip it like [2].

Then, I got this:

  { kernel version }	: { average } 
  5.15.0				: 585577
  5.16.0-rc4			: 514959
  5.16.0-rc4 + [1]		: 575066
  5.16.0-rc4 + [2]		: 597201

I think at least the last case serves as a proof of concept for this issue.

Thanks,
Chang


[1] tglx’s diff shown in here: https://lore.kernel.org/lkml/87bl1s357p.ffs@tglx/

[2] 
diff --git a/kernel/signal.c b/kernel/signal.c
index a629b11bf3e0..8194d2f38bf1 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -4224,6 +4224,11 @@ int restore_altstack(const stack_t __user *uss)
        stack_t new;
        if (copy_from_user(&new, uss, sizeof(stack_t)))
                return -EFAULT;
+       if (current->sas_ss_sp == (unsigned long) new.ss_sp &&
+           current->sas_ss_size == new.ss_size &&
+           current->sas_ss_flags == new.ss_flags)
+               return 0;
+
        (void)do_sigaltstack(&new, NULL, current_user_stack_pointer(),
                             MINSIGSTKSZ);
        /* squash all but EFAULT for now */


  reply	other threads:[~2021-12-08 18:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-07  1:21 kernel test robot
2021-12-07  1:44 ` Oliver Sang
2021-12-07 13:38 ` Thomas Gleixner
2021-12-07 18:49   ` Bae, Chang Seok
2021-12-07 20:36     ` Thomas Gleixner
2021-12-07 22:17       ` Bae, Chang Seok
2021-12-08  0:59         ` Yin Fengwei
2021-12-09  2:30   ` [LKP] " Carel Si
2021-12-07 23:14 ` Dave Hansen
2021-12-08 18:00   ` Bae, Chang Seok [this message]
2021-12-08 18:20     ` Dave Hansen
2021-12-08 19:14       ` Thomas Gleixner
2021-12-09  8:13       ` Thomas Gleixner
2021-12-10  4:15   ` [LKP] " Carel Si

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=DF832BC5-AB0F-44AD-83C3-E0108176F945@intel.com \
    --to=chang.seok.bae@intel.com \
    --cc=bp@suse.de \
    --cc=dave.hansen@intel.com \
    --cc=feng.tang@intel.com \
    --cc=fengwei.yin@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=lkp@lists.01.org \
    --cc=oliver.sang@intel.com \
    --cc=tglx@linutronix.de \
    --cc=ying.huang@intel.com \
    --cc=zhengjun.xing@linux.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

all inboxes | Powered by JetHome®