Re: [PATCH] docs: admin-guide: remove obsolete advice related to SLAB allocator

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

 



On 11/30/23 10:55, Lukas Bulwahn wrote:
> Commit 1db9d06aaa55 ("mm/slab: remove CONFIG_SLAB from all Kconfig and

Note that's a -next (from slab/for-next) commit which might still change at
this point.

> Makefile") removes the config SLAB and makes the SLUB allocator the only
> default allocator in the kernel. Hence, the advice on reducing OS jitter
> due to kworker kernel threads to build with CONFIG_SLUB instead of
> CONFIG_SLAB is obsolete.
> 
> Remove the obsolete advice to build with SLUB instead of SLAB.
> 
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx>

Acked-by: Vlastimil Babka <vbabka@xxxxxxx>

But due to above, maybe it's best to wait after the removal goes through.

> ---
>  .../admin-guide/kernel-per-CPU-kthreads.rst      | 16 ++++++----------
>  1 file changed, 6 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-per-CPU-kthreads.rst b/Documentation/admin-guide/kernel-per-CPU-kthreads.rst
> index 993c2a05f5ee..b6aeae3327ce 100644
> --- a/Documentation/admin-guide/kernel-per-CPU-kthreads.rst
> +++ b/Documentation/admin-guide/kernel-per-CPU-kthreads.rst
> @@ -243,13 +243,9 @@ To reduce its OS jitter, do any of the following:
>  3.	Do any of the following needed to avoid jitter that your
>  	application cannot tolerate:
>  
> -	a.	Build your kernel with CONFIG_SLUB=y rather than
> -		CONFIG_SLAB=y, thus avoiding the slab allocator's periodic
> -		use of each CPU's workqueues to run its cache_reap()
> -		function.
> -	b.	Avoid using oprofile, thus avoiding OS jitter from
> +	a.	Avoid using oprofile, thus avoiding OS jitter from
>  		wq_sync_buffer().
> -	c.	Limit your CPU frequency so that a CPU-frequency
> +	b.	Limit your CPU frequency so that a CPU-frequency
>  		governor is not required, possibly enlisting the aid of
>  		special heatsinks or other cooling technologies.  If done
>  		correctly, and if you CPU architecture permits, you should
> @@ -259,7 +255,7 @@ To reduce its OS jitter, do any of the following:
>  
>  		WARNING:  Please check your CPU specifications to
>  		make sure that this is safe on your particular system.
> -	d.	As of v3.18, Christoph Lameter's on-demand vmstat workers
> +	c.	As of v3.18, Christoph Lameter's on-demand vmstat workers
>  		commit prevents OS jitter due to vmstat_update() on
>  		CONFIG_SMP=y systems.  Before v3.18, is not possible
>  		to entirely get rid of the OS jitter, but you can
> @@ -274,7 +270,7 @@ To reduce its OS jitter, do any of the following:
>  		(based on an earlier one from Gilad Ben-Yossef) that
>  		reduces or even eliminates vmstat overhead for some
>  		workloads at https://lore.kernel.org/r/00000140e9dfd6bd-40db3d4f-c1be-434f-8132-7820f81bb586-000000@xxxxxxxxxxxxxxxxxxx.
> -	e.	If running on high-end powerpc servers, build with
> +	d.	If running on high-end powerpc servers, build with
>  		CONFIG_PPC_RTAS_DAEMON=n.  This prevents the RTAS
>  		daemon from running on each CPU every second or so.
>  		(This will require editing Kconfig files and will defeat
> @@ -282,12 +278,12 @@ To reduce its OS jitter, do any of the following:
>  		due to the rtas_event_scan() function.
>  		WARNING:  Please check your CPU specifications to
>  		make sure that this is safe on your particular system.
> -	f.	If running on Cell Processor, build your kernel with
> +	e.	If running on Cell Processor, build your kernel with
>  		CBE_CPUFREQ_SPU_GOVERNOR=n to avoid OS jitter from
>  		spu_gov_work().
>  		WARNING:  Please check your CPU specifications to
>  		make sure that this is safe on your particular system.
> -	g.	If running on PowerMAC, build your kernel with
> +	f.	If running on PowerMAC, build your kernel with
>  		CONFIG_PMAC_RACKMETER=n to disable the CPU-meter,
>  		avoiding OS jitter from rackmeter_do_timer().
>  





[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux