mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tim Chen <tim.c.chen@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Chris Mason <clm@meta.com>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: futex performance regression from "futex: Allow automatic allocation of process wide futex hash"
Date: Fri, 27 Jun 2025 15:48:12 -0700	[thread overview]
Message-ID: <079dd4850554107056c536cbcb321572deaa8fde.camel@linux.intel.com> (raw)
In-Reply-To: <20250624190118.GB1490279@noisy.programming.kicks-ass.net>

On Tue, 2025-06-24 at 21:01 +0200, Peter Zijlstra wrote:
> 
> How about something like this (very lightly tested)...
> 
> the TL;DR is that it turns all those refcounts into per-cpu ops when
> there is no hash replacement pending (eg. the normal case), and only
> folds the lot into an atomic when we really care about it.
> 
> There's some sharp corners still.. but it boots and survives the
> (slightly modified) selftest.
> 
> ---
>  include/linux/futex.h                              |  12 +-
>  include/linux/mm_types.h                           |   5 +
>  kernel/futex/core.c                                | 238 +++++++++++++++++++--
>  .../selftests/futex/functional/futex_priv_hash.c   |  11 +-
>  4 files changed, 239 insertions(+), 27 deletions(-)
> 
> diff --git a/include/linux/futex.h b/include/linux/futex.h
> index b37193653e6b..5f92c7a8ba57 100644
> --- a/include/linux/futex.h
> +++ b/include/linux/futex.h
> @@ -85,17 +85,11 @@ int futex_hash_prctl(unsigned long arg2, unsigned long arg3, unsigned long arg4)
>  #ifdef CONFIG_FUTEX_PRIVATE_HASH
>  int futex_hash_allocate_default(void);
>  void futex_hash_free(struct mm_struct *mm);
> -
> -static inline void futex_mm_init(struct mm_struct *mm)
> -{
> -	RCU_INIT_POINTER(mm->futex_phash, NULL);
> -	mm->futex_phash_new = NULL;
> -	mutex_init(&mm->futex_hash_lock);
> -}
> +int futex_mm_init(struct mm_struct *mm);
>  
>  #else /* !CONFIG_FUTEX_PRIVATE_HASH */
>  static inline int futex_hash_allocate_default(void) { return 0; }
> -static inline void futex_hash_free(struct mm_struct *mm) { }
> +static inline int futex_hash_free(struct mm_struct *mm) { return 0; }

Minor nit.

futex_hash_free() is defined to return void for CONFIG_FUTEX_PRIVATE_HASH
config. But is now defined to return int for !CONFIG_FUTEX_PRIVATE_HASH and !CONFIG_FUTEX configs.
But it seems like nobody is actually checking the return value.  It
seems to make more sense to keep the return value as void here so
the return value is consistent?

Tim

>  static inline void futex_mm_init(struct mm_struct *mm) { }
>  #endif /* CONFIG_FUTEX_PRIVATE_HASH */
>  
> @@ -118,7 +112,7 @@ static inline int futex_hash_allocate_default(void)
>  {
>  	return 0;
>  }
> -static inline void futex_hash_free(struct mm_struct *mm) { }
> +static inline int futex_hash_free(struct mm_struct *mm) { return 0; }
>  static inline void futex_mm_init(struct mm_struct *mm) { }
>  
>  #endif


  parent reply	other threads:[~2025-06-27 22:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-03 19:00 Chris Mason
2025-06-04  9:28 ` Sebastian Andrzej Siewior
2025-06-04 15:48   ` Chris Mason
2025-06-04 20:08     ` Sebastian Andrzej Siewior
2025-06-06  0:55       ` Chris Mason
2025-06-06  7:06         ` Sebastian Andrzej Siewior
2025-06-06 21:06           ` Chris Mason
2025-06-06 22:17           ` Chris Mason
2025-06-24 19:01           ` Peter Zijlstra
2025-06-26 11:01             ` Chris Mason
2025-06-26 13:17               ` Peter Zijlstra
2025-06-26 13:50                 ` Sebastian Andrzej Siewior
2025-06-27 11:04                   ` Peter Zijlstra
2025-06-27 12:14                     ` Sebastian Andrzej Siewior
2025-06-30 14:50                     ` [PATCH] futex: Temporary disable FUTEX_PRIVATE_HASH Sebastian Andrzej Siewior
2025-07-01 13:13                       ` [tip: locking/urgent] " tip-bot2 for Sebastian Andrzej Siewior
2025-07-16  1:34                       ` [PATCH] " kernel test robot
2025-06-26 13:48             ` futex performance regression from "futex: Allow automatic allocation of process wide futex hash" Sebastian Andrzej Siewior
2025-06-26 14:36               ` Peter Zijlstra
2025-06-27 12:24                 ` Sebastian Andrzej Siewior
2025-06-27 22:48             ` Tim Chen [this message]
2025-06-28  8:23               ` Peter Zijlstra

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=079dd4850554107056c536cbcb321572deaa8fde.camel@linux.intel.com \
    --to=tim.c.chen@linux.intel.com \
    --cc=bigeasy@linutronix.de \
    --cc=clm@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /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®