Messages in this thread | | | Subject | Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up | From | Byungchul Park <> | Date | Fri, 1 Jun 2018 15:30:43 +0900 |
| |
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
| |