[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <11a4ca6a-9534-4f3d-bda6-4caf460c6854@kernel.org>
Date: Fri, 6 Feb 2026 10:03:49 +0100
From: "David Hildenbrand (Arm)" <david@...nel.org>
To: Dev Jain <dev.jain@....com>, Vernon Yang <vernon2gm@...il.com>
Cc: akpm@...ux-foundation.org, lorenzo.stoakes@...cle.com, ziy@...dia.com,
baohua@...nel.org, lance.yang@...ux.dev, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Vernon Yang <yanglincheng@...inos.cn>
Subject: Re: [PATCH mm-new v6 2/5] mm: khugepaged: refine scan progress number
On 2/5/26 15:30, Dev Jain wrote:
>
> On 05/02/26 7:55 pm, Dev Jain wrote:
>> On 05/02/26 5:41 pm, David Hildenbrand (arm) wrote:
>>> Yes!
>>>
>>> Why do we even have to optimize this? :)
>>>
>>> Premature ... ? :)
>>
>> I mean .... we don't, but the alternate is a one liner using max().
>>
>> The objective is to compute the number of iterations of the for-loop.
>>
>> It just seems weird to me to track that in the loop, when we have the
>>
>> loop iterator, which *literally* does that only.
>
> I realize I shouldn't have bolded out the "literally" - below I wrote that
> I won't shout, but the bold seems like shouting :)
Heh.
The thing is that the loop iterator does not quite what we want,
otherwise we wouldn't have to mess with max() etc.
--
Cheers,
David
Powered by blists - more mailing lists