Re: [PATCH 1/1] mm: vmalloc: Optimize vmap_lazy_nr arithmetic when purging each vmap_area

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Le 30/08/2024 à 18:26, Uladzislau Rezki a écrit :

At least in my case, HW, i do not see that atomic_long_add_return() is a
top when it comes to CPU cycles. Below one is the hottest instead:

static bool
is_vn_id_valid(unsigned int node_id)
{
	if (node_id < nr_vmap_nodes)
		return true;

	return false;
}

access to "nr_vmap_nodes" which is read-only and globally defined:

static __read_mostly unsigned int nr_vmap_nodes = 1;

Any thoughts?

--
Uladzislau Rezki


Hi,

unrelated to your use case, but something that coud easily save a few cycles on some system, IMHO.

Maybe:

#if NR_CPUS > 1
static __read_mostly unsigned int nr_vmap_nodes = 1;
static __read_mostly unsigned int vmap_zone_size = 1;
#else
#define nr_vmap_nodes	1
#define vmap_zone_size	1
#endif

So that the compiler can do a better job because some loops can be optimized away and there is no need to access some memory to get theses values.

Not sure if such a use case can exist or is of any interest.

This is valide because of [1] and the #ifdef around the num_possible_cpus() declaration [2, 3].


Just my 2c.

CJ

[1]: https://elixir.bootlin.com/linux/v6.11-rc5/source/mm/vmalloc.c#L5026

[2]: https://elixir.bootlin.com/linux/v6.11-rc5/source/include/linux/cpumask.h#L1083 [3]: https://elixir.bootlin.com/linux/v6.11-rc5/source/include/linux/cpumask.h#L1136




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux