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: <pj6wif5dkwu5ayqqypvm77wv6dncnpx6sanh46u672gr2yxxss@56s4feeu5auu>
Date: Tue, 14 Jan 2025 10:32:02 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Christian Loehle <christian.loehle@....com>, 
	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:40:00PM +0100, Peter Zijlstra wrote:
> On Tue, Jan 14, 2025 at 01:29:04PM +0000, Christian Loehle wrote:
> 
> > I know nothing about bcachefs internals, but could this also be a problem?
> > The rebalance thread might not run for O(second) or so? 
> 
> SCHED_BATCH should not behave anything like that, mostly SCHED_BATCH
> tasks will not cause wakeup preemption. But otherwise they compete at
> the same level as everybody else.
> 
> Notably a BATCH and NORMAL task that are each while(1) loops will get
> the normal 50-50 distribution of time. It's just that when a NORMAL task
> is running, the waking of a BATCH task won't ever kick the NORMAL from
> the CPU, instead waiting for the tick to do so.
> 
> So a task that is IO heavy (as suggested here), that wakes a lot to
> issue further IO, will not immediately interrupt whatever is on the CPU,
> instead it waits until it gets selected through other means.

Ok, thanks for the clarification on SCHED_BATCH - that does make perfect
sense here.

Using nice as a proxy for io scheduler priority does still bug me a bit,
simply because having a working io scheduler is not something we've ever
been able to depend on. That's a hidden internal knob we'd like to make
visible. I wonder if there's some way the tooling could be improved.