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
next prev parent 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.