linux-kernel - Re: [PATCH 2/2] bcachefs: set rebalance thread to SCHED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <yry5ukfmnfcfemtebcfxgg3mbueil7rgakqzfzdsx6iqn4ush7@3iuxjdj5sdoe>
Date: Tue, 14 Jan 2025 10:25:42 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Florian Schmaus <flo@...kplace.eu>, Ingo Molnar <mingo@...hat.com>, 
	Juri Lelli <juri.lelli@...hat.com>, Vincent Guittot <vincent.guittot@...aro.org>, 
	Dietmar Eggemann <dietmar.eggemann@....com>, Steven Rostedt <rostedt@...dmis.org>, 
	Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>, 
	Valentin Schneider <vschneid@...hat.com>, linux-bcachefs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] bcachefs: set rebalance thread to SCHED_BATCH and
 nice 19

On Tue, Jan 14, 2025 at 03:32:14PM +0100, Peter Zijlstra wrote:
> On Tue, Jan 14, 2025 at 01:47:28PM +0100, Florian Schmaus wrote:
> > While the rebalance thread is isually not compute bound, it does cause
> > a considerable amount of I/O. Since "reducing" the nice level from 0
> > to 19, also implicitly reduces the threads best-effort I/O scheduling
> > class level from 4 to 7, the reblance thread's I/O will be depriotized
> > over normal I/O.
> > 
> > Furthermore, we set the rebalance thread's scheduling class to BATCH,
> > which means that it will potentially receive a higher scheduling
> > latency. Making room for threads that need a low
> > schedulinglatency (e.g., interactive onces).
> 
> sorta.. what worries me most about these patches are the claims without
> backing numbers.
> 
> Supposedly there is a problem, and this here fixes it, but it doesn't
> really get quantified much here.

yeah, it was explained to me and made sense at the time, but things
somehow keep falling out of my overflowing brain.

Florian, could you update the patch message with that? Was it intended
as a partial workaround for the rebalance spinning issue some users have
been hitting?