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> Link: https://lkml.kernel.org/r/20250417161216.88318-4-urezki@gmail.com Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com> Reviewed-by: Baoquan He <bhe@redhat.com> Reviewed-by: Adrian Huang <ahuang12@lenovo.com> Tested-by: Adrian Huang <ahuang12@lenovo.com> Cc: Mateusz Guzik <mjguzik@gmail.com> Cc: Christop Hellwig <hch@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>pull/1253/head
parent
7a6fe58777
commit
d096612048
|
|
@ -1008,7 +1008,8 @@ static BLOCKING_NOTIFIER_HEAD(vmap_notify_list);
|
||||||
static void drain_vmap_area_work(struct work_struct *work);
|
static void drain_vmap_area_work(struct work_struct *work);
|
||||||
static DECLARE_WORK(drain_vmap_work, drain_vmap_area_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)
|
unsigned long vmalloc_nr_pages(void)
|
||||||
{
|
{
|
||||||
|
|
@ -2117,8 +2118,6 @@ static unsigned long lazy_max_pages(void)
|
||||||
return log * (32UL * 1024 * 1024 / PAGE_SIZE);
|
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
|
* Serialize vmap purging. There is no actual critical section protected
|
||||||
* by this lock, but we want to avoid concurrent calls for performance
|
* by this lock, but we want to avoid concurrent calls for performance
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue