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 for Android: free password hash cracker in your pocket

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

Message-ID: <866f8d37-2ef5-434b-bf70-f142fbbcfc62@arm.com>
Date: Tue, 14 Jan 2025 15:05:29 +0000
From: Christian Loehle <christian.loehle@....com>
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>,
 Kent Overstreet <kent.overstreet@...ux.dev>, 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 1/14/25 14:40, 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.

I was thinking about two SCHED_BATCH tasks here and one having to wait
for a long time for it to complete, but that was because I was still
under the impression that SCHED_BATCH uses a different base slice which
apparently isn't true. My bad!