Received-SPF: pass (google.com: domain of linux-kernel+bounces-199395-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <788a0c8a-79b9-4a06-9739-8b62498bde90@arm.com>
Date: Mon, 3 Jun 2024 16:57:15 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC][PATCH 08/10] sched/fair: Implement delayed dequeue
To: Peter Zijlstra <peterz@infradead.org>, Luis Machado <luis.machado@arm.com>
Cc: linux-kernel@vger.kernel.org
References: <20240405102754.435410987@infradead.org>
 <20240405110010.631664251@infradead.org>
 <3888d7c8-660e-479c-8c10-8295204e5f36@arm.com>
 <1461277e-af68-41e7-947c-9178b55810b1@arm.com>
 <20240425104220.GE21980@noisy.programming.kicks-ass.net>
 <20240425114949.GH12673@noisy.programming.kicks-ass.net>
 <20240426093241.GI12673@noisy.programming.kicks-ass.net>
 <c6152855-ef92-4c24-a3f5-64d4256b6789@arm.com>
 <20240523084548.GI40213@noisy.programming.kicks-ass.net>
 <e4b472c9-ad8b-4423-81ad-02a1ab231f95@arm.com>
 <20240523093338.GJ40213@noisy.programming.kicks-ass.net>
Content-Language: en-US
From: Hongyan Xia <hongyan.xia2@arm.com>
In-Reply-To: <20240523093338.GJ40213@noisy.programming.kicks-ass.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 23/05/2024 10:33, Peter Zijlstra wrote:
> On Thu, May 23, 2024 at 10:06:04AM +0100, Luis Machado wrote:
> 
>> Booting the kernel with NO_DELAY_DEQUEUE (default to false), things work fine. Then
>> if I switch to DELAY_DEQUEUE at runtime, things start using a lot more power.
>>
>> The interesting bit is if I switch to NO_DELAY_DEQUEUE again at runtime, things don't
>> go back to normal. Rather they stay the same, using a lot more energy.
> 
> Ooh, cute.. weird. I'll try and see if we leak state somehow.

Hi. I'm working on uclamp anyway so I just gave this series (and all 
fixes mentioned in this thread) a go.

It seems after running with this series for a while, suddenly uclamp_max 
no longer works. Running a task with uclamp_max of 110 still sees an rq 
uclamp_max of 1024. Also weirdly, the PELT signal of that uclamp_max is 
completely broken. It goes up to a very high value and then suddenly 
drops to almost 0 from time to time.

I wonder if the reason Luis saw that is because he was the first one to 
run delayed dequeue with uclamp. I'm not familiar enough with the series 
to know how it could possibly affect uclamp so investigating in this 
front may be worth trying. Maybe some leaked uclamp state on the rq?