lkml.org 
[lkml]   [2018]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up
From
Date


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

\
 
 \ /
  Last update: 2018-06-01 08:31    [W:0.113 / U:1.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site