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 Apr 2024 09:48:36 +0300
From: Alexandru Ardelean <alex@...uggie.ro>
To: Valentin Schneider <vschneid@...hat.com>
Cc: linux-kernel@...r.kernel.org, mingo@...hat.com, peterz@...radead.org, 
	juri.lelli@...hat.com, vincent.guittot@...aro.org, dietmar.eggemann@....com, 
	rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de, bristot@...hat.com, 
	tian.xianting@....com, steffen.aschbacher@...hl.de, 
	gregkh@...uxfoundation.org
Subject: Re: [PATCH][V2] sched/rt: Print curr when RT throttling activated

On Mon, Apr 8, 2024 at 6:25 PM Valentin Schneider <vschneid@...hat.com> wrote:
>
> On 01/04/24 18:47, Alexandru Ardelean wrote:
> > On Thu, Jul 13, 2023 at 11:07 PM Alexandru Ardelean <alex@...uggie.ro> wrote:
> >>
> >> On Tue, May 16, 2023 at 3:22 PM Alexandru Ardelean <alex@...uggie.ro> wrote:
> >> >
> >> > From: Xianting Tian <tian.xianting@....com>
> >> >
> >> > We may meet the issue, that one RT thread occupied the cpu by 950ms/1s,
> >> > The RT thread maybe is a business thread or other unknown thread.
> >> >
> >> > Currently, it only outputs the print "sched: RT throttling activated"
> >> > when RT throttling happen. It is hard to know what is the RT thread,
> >> > For further analysis, we need add more prints.
> >> >
> >> > This patch is to print current RT task when RT throttling activated,
> >> > It help us to know what is the RT thread in the first time.
> >> >
> >>
> >> Adding Greg on this patch, since it 's been a while.
> >> And also: ping :)
> >
> > Ping on this :)
> >
>
> AFAIA this has been proposed a few times in the past, the problem is that
> printing the current task isn't the right thing to do as it may not be the
> one that contributed most of the runtime that lead to throttling.
>
> See https://lore.kernel.org/lkml/20221209163606.53a2370e@gandalf.local.home/

Ah.
Thanks for the input :)
I'll shut up on this.

Thanks
Alex

>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ