Commit 1db9d06aaa55 ("mm/slab: remove CONFIG_SLAB from all Kconfig and
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 <[email protected]>
---
.../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().
--
2.17.1
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 <[email protected]>
Acked-by: Vlastimil Babka <[email protected]>
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().
>
Vlastimil Babka <[email protected]> writes:
> 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 <[email protected]>
>
> Acked-by: Vlastimil Babka <[email protected]>
>
> But due to above, maybe it's best to wait after the removal goes through.
That has definitely happened, so I've applied this now.
Thanks,
jon