All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	kernel test robot <rong.a.chen@intel.com>,
	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: Wed, 11 Mar 2020 09:20:00 +0100	[thread overview]
Message-ID: <20200311082000.GA724@ulmo> (raw)
In-Reply-To: <87h7yy90ve.fsf@nanos.tec.linutronix.de>

[-- Attachment #1: Type: text/plain, Size: 2090 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)];
>  }

I was running into an issue with sshfs mounts and git bisect pointed to
the "futex: Fix inode life-time issue" commit as being the culprit. The
issue I was seeing is that an sshfs mount would succeed, but trying to
then access the mount ("ls -l /mnt" would be enough) would cause a soft
lock-up.

Applying this fix on top of next-20200310 fixes the issue for me, so:

Tested-by: Thierry Reding <treding@nvidia.com>

I still need that fix on next-20200311, but it'll probably show up in
linux-next sometime soon.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: lkp@lists.01.org
Subject: Re: [futex] 8019ad13ef: will-it-scale.per_process_ops -97.8% regression
Date: Wed, 11 Mar 2020 09:20:00 +0100	[thread overview]
Message-ID: <20200311082000.GA724@ulmo> (raw)
In-Reply-To: <87h7yy90ve.fsf@nanos.tec.linutronix.de>

[-- Attachment #1: Type: text/plain, Size: 2090 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)];
>  }

I was running into an issue with sshfs mounts and git bisect pointed to
the "futex: Fix inode life-time issue" commit as being the culprit. The
issue I was seeing is that an sshfs mount would succeed, but trying to
then access the mount ("ls -l /mnt" would be enough) would cause a soft
lock-up.

Applying this fix on top of next-20200310 fixes the issue for me, so:

Tested-by: Thierry Reding <treding@nvidia.com>

I still need that fix on next-20200311, but it'll probably show up in
linux-next sometime soon.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2020-03-11  8:20 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
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       ` Thierry Reding [this message]
2020-03-11  8:20         ` [futex] 8019ad13ef: will-it-scale.per_process_ops -97.8% regression 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=20200311082000.GA724@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=bp@suse.de \
    --cc=jannh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@lists.01.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rong.a.chen@intel.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.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.