linux-kernel - RE: [PATCH 4/4] vmalloc: Align nr_vmalloc_pages and vmap_lazy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID:
 <TYZPR03MB61927CAD315EEC000854481BB3852@TYZPR03MB6192.apcprd03.prod.outlook.com>
Date: Thu, 24 Apr 2025 13:38:57 +0000
From: Adrian Huang12 <ahuang12@...ovo.com>
To: "Uladzislau Rezki (Sony)" <urezki@...il.com>,
        Andrew Morton
	<akpm@...ux-foundation.org>
CC: "linux-mm@...ck.org" <linux-mm@...ck.org>,
        LKML
	<linux-kernel@...r.kernel.org>, Baoquan He <bhe@...hat.com>,
        Christoph
 Hellwig <hch@...radead.org>,
        Oleksiy Avramchenko
	<oleksiy.avramchenko@...y.com>,
        Mateusz Guzik <mjguzik@...il.com>
Subject: RE: [PATCH 4/4] vmalloc: Align nr_vmalloc_pages and vmap_lazy_nr

> -----Original Message-----
> From: owner-linux-mm@...ck.org <owner-linux-mm@...ck.org> On Behalf
> Of Uladzislau Rezki (Sony)
> Sent: Friday, April 18, 2025 12:12 AM
> To: Andrew Morton <akpm@...ux-foundation.org>
> Cc: linux-mm@...ck.org; LKML <linux-kernel@...r.kernel.org>; Baoquan He
> <bhe@...hat.com>; Christoph Hellwig <hch@...radead.org>; Uladzislau Rezki
> <urezki@...il.com>; Oleksiy Avramchenko <oleksiy.avramchenko@...y.com>;
> Mateusz Guzik <mjguzik@...il.com>
> Subject: [External] [PATCH 4/4] vmalloc: Align nr_vmalloc_pages and
> vmap_lazy_nr
> 
> Currently both atomics share one cache-line:
> 
> <snip>
> ...
> ffffffff83eab400 b vmap_lazy_nr
> ffffffff83eab408 b nr_vmalloc_pages
> ...
> <snip>
> 
> those are global variables and they are only 8 bytes apart.
> Since they are modified by different threads this causes a false sharing. This
> can lead to a performance drop due to unnecessary cache invalidations.
> 
> After this patch it is aligned to a cache line boundary:
> 
> <snip>
> ...
> ffffffff8260a600 d vmap_lazy_nr
> ffffffff8260a640 d nr_vmalloc_pages
> ...
> <snip>
> 
> Cc: Mateusz Guzik <mjguzik@...il.com>
> Signed-off-by: Uladzislau Rezki (Sony) <urezki@...il.com>
> ---
>  mm/vmalloc.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)

Reviewed-by: Adrian Huang <ahuang12@...ovo.com>
Tested-by: Adrian Huang <ahuang12@...ovo.com>

> diff --git a/mm/vmalloc.c b/mm/vmalloc.c index
> 77da4613f07ff..54f60d62051da 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -1008,7 +1008,8 @@ static BLOCKING_NOTIFIER_HEAD(vmap_notify_list);
>  static void drain_vmap_area_work(struct work_struct *work);  static
> DECLARE_WORK(drain_vmap_work, drain_vmap_area_work);
> 
> -static atomic_long_t nr_vmalloc_pages;
> +static __cacheline_aligned_in_smp atomic_long_t nr_vmalloc_pages;
> +static __cacheline_aligned_in_smp atomic_long_t vmap_lazy_nr;
> 
>  unsigned long vmalloc_nr_pages(void)
>  {
> @@ -2117,8 +2118,6 @@ static unsigned long lazy_max_pages(void)
>  	return log * (32UL * 1024 * 1024 / PAGE_SIZE);  }
> 
> -static atomic_long_t vmap_lazy_nr = ATOMIC_LONG_INIT(0);
> -
>  /*
>   * Serialize vmap purging.  There is no actual critical section protected
>   * by this lock, but we want to avoid concurrent calls for performance
> --
> 2.39.5
>