linux-kernel - RE: [REGRESSION] Re: [PATCH 00/24] Complete EEVDF

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: <001301db6aef$35aa1ab0$a0fe5010$@telus.net>
Date: Sun, 19 Jan 2025 19:55:56 -0800
From: "Doug Smythies" <dsmythies@...us.net>
To: "'Peter Zijlstra'" <peterz@...radead.org>
Cc: <linux-kernel@...r.kernel.org>,
	<vincent.guittot@...aro.org>,
	"'Ingo Molnar'" <mingo@...nel.org>,
	<wuyun.abel@...edance.com>,
	"Doug Smythies" <dsmythies@...us.net>
Subject: RE: [REGRESSION] Re: [PATCH 00/24] Complete EEVDF

Hi Peter,

I now know that the 2nd issue I mentioned yesterday
is a completely separate issue. I would have to do
a new kernel bisection to isolate it and then start
a new thread with whomever about it.

On 2025.01.18 16:09 Doug Smythies wrote:

> Hi Peter,
> 
> An update.
>
> On 2025.01.14 02:59 Peter Zijlstra wrote:
>> On Mon, Jan 13, 2025 at 12:03:12PM +0100, Peter Zijlstra wrote:
>>> On Sun, Jan 12, 2025 at 03:14:17PM -0800, Doug Smythies wrote:
>
>>>> means that there were 19 occurrences of turbostat interval times
>>>> between 1.016 and 1.016999 seconds.
>>> 
>>> OK, let me lower my threshold to 10ms and change the turbostat
>>> invocation -- see if I can catch me some wabbits :-)
>>
>> I've had it run overnight and have not caught a single >10ms event :-(
>
> Okay, so both you and I have many many hours of testing and
> never see >= 10ms in that area of the turbostat code anymore.
>
> The lingering >= 10ms (but I have never seen more than 25 ms)
> is outside of that timing.

... snip ...

> I am saying there were 2 different issues. The 2nd was hidden by the 1st
> because its magnitude was about 260 times less.

The first issue was solved by your two commits of this thread and now in
Kernel 6.13:

66951e4860d3 sched/fair: Fix update_cfs_group() vs DELAY_DEQUEUE
6d71a9c61604 sched/fair: Fix EEVDF entity placement bug causing scheduling lag

The second issue is not present in my original kernel bisection for the first
bad kernel and must have been introduced later on.