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] [day] [month] [year] [list]
Date: Wed, 17 Jan 2024 16:48:14 +0800
From: Alex Shi <seakeel@...il.com>
To: Valentin Schneider <vschneid@...hat.com>
Cc: alexs@...nel.org, Ingo Molnar <mingo@...hat.com>, 
	Peter Zijlstra <peterz@...radead.org>, 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>, 
	Daniel Bristot de Oliveira <bristot@...hat.com>, linux-kernel@...r.kernel.org, curuwang@...cent.com
Subject: Re: [PATCH v2] sched/stat: correct the task blocking state

Alex Shi <seakeel@...il.com> 于2024年1月4日周四 19:29写道:
>
> On Thu, Jan 4, 2024 at 6:38 PM Valentin Schneider <vschneid@...hat.com> wrote:
> >
> > On 03/01/24 16:10, alexs@...nel.org wrote:
> > > From: Alex Shi <alexs@...nel.org>
> > >
> > > The commit 80ed87c8a9ca ("sched/wait: Introduce TASK_NOLOAD and TASK_IDLE")
> > > stopped the idle kthreads from contributing to the load average. However,
> > > the idle state time still contributes to the blocked state time instead of
> > > the sleep time. As a result, we cannot determine if a task is stopped due
> > > to some reasons or if it is idle by its own initiative.
> > >
> > > Distinguishing between these two states would make the system state clearer
> > > and provide us with an opportunity to use the 'D' state of a task as an
> > > indicator of latency issues.
> > >
> >
> > get_task_state() already reports TASK_IDLE as 'I', which should be what
> > userspace sees (e.g. via /proc/$pid/stat). This is also the case for the
> > sched_switch and sched_wakeup trace events.
> >
> > I assume what you mean here is you first turn to schedstats to check
> > whether there is any abnormal amount of blocking, and then if there is any
> > you turn to tracing, in which case you'd like the schedstats to not make
> > things look worse than they really are?
>
> Yes, switch/wakeup or others could help to figure out real blocked
> time, but with this change, schedstats could give a neat and elegant
> way.

For all of the shortages I can imagine, we can't treat blocked and
sleep states as before,  and that may force some scripts to change on
these things, but giving 2 states the correct way is better way, and
make sleep/block state more meaningful and helpful in normal usage.
Are there any concerns on this?

Thanks
Alex

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ