All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <rong.a.chen@intel.com>
To: lkp@lists.01.org
Subject: Re: [futex] 8019ad13ef: will-it-scale.per_process_ops -97.8% regression
Date: Mon, 09 Mar 2020 16:26:49 +0800	[thread overview]
Message-ID: <20200309082649.GT5972@shao2-debian> (raw)
In-Reply-To: <87h7yy90ve.fsf@nanos.tec.linutronix.de>

[-- Attachment #1: Type: text/plain, Size: 2393 bytes --]

On Sun, Mar 08, 2020 at 07:07:17PM +0100, Thomas Gleixner wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
> > [ Just a re-send without html crud that makes all the lists unhappy.
> > I'm still on the road, the flight I was supposed to be on yesterday
> > got cancelled.. ]
> >
> > I do note that the futex hashing seems to be broken by that commit. Or
> > at least it's questionable.  It keeps hashing on "both.word",  and
> > doesn't use the u64 field at all for hashing.
> >
> > Maybe I'm mis-reading it - I didn't apply the patch, I just looked at
> > the patch and my source base separately.
> >
> > But the 98% regression sure says something went wrong ;)
> 
> Right you are. The pointer needs to be the starting point as it moved
> ahead of word, which means it starts at word and hashes word and
> offset and an extra u32 beyond the end of the key.
> 
> Thanks,
> 
>         tglx
> ----
> diff --git a/kernel/futex.c b/kernel/futex.c
> index e14f7cd45dbd..9f3251349f65 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -385,8 +385,8 @@ static inline int hb_waiters_pending(struct futex_hash_bucket *hb)
>   */
>  static struct futex_hash_bucket *hash_futex(union futex_key *key)
>  {
> -	u32 hash = jhash2((u32*)&key->both.word,
> -			  (sizeof(key->both.word)+sizeof(key->both.ptr))/4,
> +	u32 hash = jhash2((u32*)&key->both.ptr,
> +			  (sizeof(key->both.ptr) + sizeof(key->both.word)) / 4,
>  			  key->both.offset);
>  	return &futex_queues[hash & (futex_hashsize - 1)];
>  }

Hi Thomas,

I have tested the above patch, and the patch can fix the regression.

commit:
  v5.6-rc4
  8019ad13ef ("futex: Fix inode life-time issue")
  8eb641cbc3 ("the fix patch")

        v5.6-rc4  8019ad13ef7f64be44d4f892af  8eb641cbc397e3bbea2a9974e0  testcase/testparams/testbox
----------------  --------------------------  --------------------------  ---------------------------
         %stddev      change         %stddev      change         %stddev
             \          |                \          |                \  
   1083510             -98%      23904                     1078868        will-it-scale/performance-process-100%-futex2-ucode=0x2000065/lkp-skl-fpga01
   1083510             -98%      23904                     1078868        GEO-MEAN will-it-scale.per_process_ops

Best Regards,
Rong Chen

WARNING: multiple messages have this Message-ID (diff)
From: kernel test robot <rong.a.chen@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Jann Horn <jannh@google.com>, LKML <linux-kernel@vger.kernel.org>,
	x86-ml <x86@kernel.org>, Ingo Molnar <mingo@kernel.org>,
	Borislav Petkov <bp@suse.de>,
	lkp@lists.01.org
Subject: Re: [futex] 8019ad13ef: will-it-scale.per_process_ops -97.8% regression
Date: Mon, 9 Mar 2020 16:26:49 +0800	[thread overview]
Message-ID: <20200309082649.GT5972@shao2-debian> (raw)
In-Reply-To: <87h7yy90ve.fsf@nanos.tec.linutronix.de>

On Sun, Mar 08, 2020 at 07:07:17PM +0100, Thomas Gleixner wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
> > [ Just a re-send without html crud that makes all the lists unhappy.
> > I'm still on the road, the flight I was supposed to be on yesterday
> > got cancelled.. ]
> >
> > I do note that the futex hashing seems to be broken by that commit. Or
> > at least it's questionable.  It keeps hashing on "both.word",  and
> > doesn't use the u64 field at all for hashing.
> >
> > Maybe I'm mis-reading it - I didn't apply the patch, I just looked at
> > the patch and my source base separately.
> >
> > But the 98% regression sure says something went wrong ;)
> 
> Right you are. The pointer needs to be the starting point as it moved
> ahead of word, which means it starts at word and hashes word and
> offset and an extra u32 beyond the end of the key.
> 
> Thanks,
> 
>         tglx
> ----
> diff --git a/kernel/futex.c b/kernel/futex.c
> index e14f7cd45dbd..9f3251349f65 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -385,8 +385,8 @@ static inline int hb_waiters_pending(struct futex_hash_bucket *hb)
>   */
>  static struct futex_hash_bucket *hash_futex(union futex_key *key)
>  {
> -	u32 hash = jhash2((u32*)&key->both.word,
> -			  (sizeof(key->both.word)+sizeof(key->both.ptr))/4,
> +	u32 hash = jhash2((u32*)&key->both.ptr,
> +			  (sizeof(key->both.ptr) + sizeof(key->both.word)) / 4,
>  			  key->both.offset);
>  	return &futex_queues[hash & (futex_hashsize - 1)];
>  }

Hi Thomas,

I have tested the above patch, and the patch can fix the regression.

commit:
  v5.6-rc4
  8019ad13ef ("futex: Fix inode life-time issue")
  8eb641cbc3 ("the fix patch")

        v5.6-rc4  8019ad13ef7f64be44d4f892af  8eb641cbc397e3bbea2a9974e0  testcase/testparams/testbox
----------------  --------------------------  --------------------------  ---------------------------
         %stddev      change         %stddev      change         %stddev
             \          |                \          |                \  
   1083510             -98%      23904                     1078868        will-it-scale/performance-process-100%-futex2-ucode=0x2000065/lkp-skl-fpga01
   1083510             -98%      23904                     1078868        GEO-MEAN will-it-scale.per_process_ops

Best Regards,
Rong Chen

  reply	other threads:[~2020-03-09  8:26 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-08 14:02 [futex] 8019ad13ef: will-it-scale.per_process_ops -97.8% regression kernel test robot
2020-03-08 14:02 ` kernel test robot
2020-03-08 14:22 ` Linus Torvalds
2020-03-08 15:28   ` Linus Torvalds
2020-03-08 15:28     ` Linus Torvalds
2020-03-08 18:07     ` Thomas Gleixner
2020-03-08 18:07       ` Thomas Gleixner
2020-03-09  8:26       ` kernel test robot [this message]
2020-03-09  8:26         ` kernel test robot
2020-03-09  8:51       ` Peter Zijlstra
2020-03-09  8:51         ` Peter Zijlstra
2020-03-09  9:34         ` Thomas Gleixner
2020-03-09  9:34           ` Thomas Gleixner
2020-03-09 21:42       ` [tip: locking/urgent] futex: Unbreak futex hashing tip-bot2 for Thomas Gleixner
2020-03-11  8:20       ` [futex] 8019ad13ef: will-it-scale.per_process_ops -97.8% regression Thierry Reding
2020-03-11  8:20         ` Thierry Reding

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=20200309082649.GT5972@shao2-debian \
    --to=rong.a.chen@intel.com \
    --cc=lkp@lists.01.org \
    /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.