linux-kernel - Re: schedstat false counting of domain load_balance() tried to move one or more tasks failed

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]

Date:   Mon, 18 Jul 2022 11:51:26 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Valentin Schneider <vschneid@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: schedstat false counting of domain load_balance() tried to move
 one or more tasks failed

On Tue, Jul 12, 2022 at 09:52:59PM -0400, Steven Rostedt wrote:
> I've been tasked to analyze the /proc/schedstat file to determine
> appropriate metrics to look after in production. So I'm looking at both the
> documentation and the code that generates it.
> 
> From the documentation at https://docs.kernel.org/scheduler/sched-stats.html
> 
> (and Documentation/scheduler/sched-stats.rst for those of you that are
> allergic to html)

I'm allergic to both, it's plain text or bust.

>        3)  # of times in this domain load_balance() tried to move one or
>            more tasks and failed, when the cpu was idle

> Thus, if we get to that check for (busiest->nr_running > 1) and fail, then
> we will increment that counter incorrectly.
> 
> Do we care? Should it be fixed? Should it be documented?

*shrug*, I suppose we can fix. People using this stuff are the sort that
are likely to read documentation instead of code.

At the same time; I suspect it's been 'broken' like forever, so who
knows what people are actually expecting today.