mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Lukas Bulwahn <lukas.bulwahn@gmail.com>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-doc@vger.kernel.org
Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] docs: admin-guide: remove obsolete advice related to SLAB allocator
Date: Fri, 1 Dec 2023 11:44:24 +0100	[thread overview]
Message-ID: <f0353b3e-9cb3-4009-9c2e-4e0912f28dc2@suse.cz> (raw)
In-Reply-To: <20231130095515.21586-1-lukas.bulwahn@gmail.com>

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@gmail.com>

Acked-by: Vlastimil Babka <vbabka@suse.cz>

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@email.amazonses.com.
> -	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().
>  


  reply	other threads:[~2023-12-01 10:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-30  9:55 Lukas Bulwahn
2023-12-01 10:44 ` Vlastimil Babka [this message]
2024-01-23 21:58   ` Jonathan Corbet

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=f0353b3e-9cb3-4009-9c2e-4e0912f28dc2@suse.cz \
    --to=vbabka@suse.cz \
    --cc=corbet@lwn.net \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas.bulwahn@gmail.com \
    /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®