linux-kernel - Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 1 Jun 2018 15:30:43 +0900
From:   Byungchul Park <byungchul.park@....com>
To:     Joel Fernandes <joel@...lfernandes.org>
Cc:     Peter Zijlstra <peterz@...radead.org>, mingo@...nel.org,
        rostedt@...dmis.org, tglx@...utronix.de, raistlin@...ux.it,
        linux-kernel@...r.kernel.org, juri.lelli@...il.com,
        bristot@...hat.com, kernel-team@....com
Subject: Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for
 clean-up



On 2018-06-01 15:02, Joel Fernandes wrote:
> On Fri, Jun 01, 2018 at 12:07:48PM +0900, Byungchul Park wrote:
>>
>>
>> On 2018-05-25 14:13, Byungchul Park wrote:
>>>
>>>
>>> On 2018-05-09 15:33, Byungchul Park wrote:
>>>> On Thu, Jan 11, 2018 at 10:07:16AM +0100, Peter Zijlstra wrote:
>>>>>
>>>>>
>>>>> Sorry for the huge delay on this, but I'll have to postpone further.
>>>>> Still busy with meltdown/spectre stuff.
>>>>
>>>> Please consider this. Even though it's not a big bug, anyway leading
>>>> mis-behavior in certain situaions.
>>>
>>> Could you see this patches, it's been too long since the start tho?
>>
>> Please, any opinion.
> 
> Just my opinion: this patch [1] is just a cosmetic change. I would argue that
> there's no readability improvement by wrapping up elements[0].dl. Infact I
> even feel that the elements[0].cpu should directly be accessed since both
> .cpu and .dl for the 0th element are directly accessed only from one place
> (cpudl_find) and only one time, and explicitly accessing index 0 makes it
> more clear that this is the root of the max-heap.
> 
> IOW I don't see any benefit in hiding it behind a wrapper which hides the
> fact that we're accessing the root of the max heap, but I don't terribly hate
> this patch and I'm Ok if maintainers and other reviewers think its worth it.

Hi Joel,

Talking about the *1st patch*, no matter whether denied or not, even
though I think it looks weird to abstract only p->elements[0].cpu with
a function, but not cp->elements[0].dl.

> thanks,
> 
>   - Joel
> 
> [1] https://patchwork.kernel.org/patch/10149099/
> 
> 

-- 
Thanks,
Byungchul