Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2018-06-01 Thread Byungchul Park




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


Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2018-06-01 Thread Byungchul Park




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


Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2018-06-01 Thread Joel Fernandes
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.

thanks,

 - Joel

[1] https://patchwork.kernel.org/patch/10149099/



Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2018-06-01 Thread Joel Fernandes
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.

thanks,

 - Joel

[1] https://patchwork.kernel.org/patch/10149099/



Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2018-05-31 Thread Byungchul Park




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.

--
Thanks,
Byungchul


Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2018-05-31 Thread Byungchul Park




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.

--
Thanks,
Byungchul


Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2018-05-24 Thread Byungchul Park



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?

--
Thanks,
Byungchul


Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2018-05-24 Thread Byungchul Park



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?

--
Thanks,
Byungchul


Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2018-05-09 Thread Byungchul Park
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.


Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2018-05-09 Thread Byungchul Park
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.


Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2018-04-23 Thread Byungchul Park

On 3/13/2018 2:52 PM, Byungchul Park wrote:

On 1/11/2018 6:07 PM, Peter Zijlstra wrote:



Sorry for the huge delay on this, but I'll have to postpone further.
Still busy with meltdown/spectre stuff.


Could you review the patch?


Hello,

Could you see the patch now?

--
Thanks,
Byungchul


Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2018-04-23 Thread Byungchul Park

On 3/13/2018 2:52 PM, Byungchul Park wrote:

On 1/11/2018 6:07 PM, Peter Zijlstra wrote:



Sorry for the huge delay on this, but I'll have to postpone further.
Still busy with meltdown/spectre stuff.


Could you review the patch?


Hello,

Could you see the patch now?

--
Thanks,
Byungchul


Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2018-03-12 Thread Byungchul Park

On 1/11/2018 6:07 PM, Peter Zijlstra wrote:



Sorry for the huge delay on this, but I'll have to postpone further.
Still busy with meltdown/spectre stuff.


Could you review the patch?

--
Thanks,
Byungchul


Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2018-03-12 Thread Byungchul Park

On 1/11/2018 6:07 PM, Peter Zijlstra wrote:



Sorry for the huge delay on this, but I'll have to postpone further.
Still busy with meltdown/spectre stuff.


Could you review the patch?

--
Thanks,
Byungchul


Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2018-02-25 Thread Byungchul Park

On 1/11/2018 6:07 PM, Peter Zijlstra wrote:



Sorry for the huge delay on this, but I'll have to postpone further.
Still busy with meltdown/spectre stuff.


Do you have time to see the patch, now that it seems to be managed
to solve those security issues?

--
Thanks,
Byungchul


Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2018-02-25 Thread Byungchul Park

On 1/11/2018 6:07 PM, Peter Zijlstra wrote:



Sorry for the huge delay on this, but I'll have to postpone further.
Still busy with meltdown/spectre stuff.


Do you have time to see the patch, now that it seems to be managed
to solve those security issues?

--
Thanks,
Byungchul


Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2018-02-08 Thread Byungchul Park

On 1/11/2018 6:07 PM, Peter Zijlstra wrote:



Sorry for the huge delay on this, but I'll have to postpone further.
Still busy with meltdown/spectre stuff.


Do you have time to see these patches and another set, now?

--
Thanks,
Byungchul


Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2018-02-08 Thread Byungchul Park

On 1/11/2018 6:07 PM, Peter Zijlstra wrote:



Sorry for the huge delay on this, but I'll have to postpone further.
Still busy with meltdown/spectre stuff.


Do you have time to see these patches and another set, now?

--
Thanks,
Byungchul


Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2018-01-11 Thread Peter Zijlstra


Sorry for the huge delay on this, but I'll have to postpone further.
Still busy with meltdown/spectre stuff.


Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2018-01-11 Thread Peter Zijlstra


Sorry for the huge delay on this, but I'll have to postpone further.
Still busy with meltdown/spectre stuff.


Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2017-12-21 Thread Byungchul Park
On Tue, Dec 19, 2017 at 10:19:23AM +0900, Byungchul Park wrote:
> Changes from v2
>  - Run spellchecker over the text and fix typos
>  - Add acked-by Daniel
> 
> Changes from v1
>  - Enhance commit msg
>  - Prevent WARN in cpumask_test_cpu() in cpudl_find() when best_cpu == -1

Hello, shall I stop sending this? Let me know if so.

> -8<-
> >From 7735382d07ae6a61d740ae39ba2ecf169d43b8a2 Mon Sep 17 00:00:00 2001
> From: Byungchul Park 
> Date: Wed, 22 Mar 2017 14:25:56 +0900
> Subject: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for 
> clean-up
> 
> Current code uses cpudl_maximum() to get the root node's cpu, while it
> directly accesses the root node like 'cp->elements[0].dl' to get the
> root node's dl. It would be more readable to add a function for the dl,
> as well. Added it.
> 
> Signed-off-by: Byungchul Park 
> Acked-by: Steven Rostedt (VMware) 
> Acked-by: Daniel Bristot de Oliveira 
> ---
>  kernel/sched/cpudeadline.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
> index 8d9562d..9f02035 100644
> --- a/kernel/sched/cpudeadline.c
> +++ b/kernel/sched/cpudeadline.c
> @@ -108,11 +108,16 @@ static void cpudl_heapify(struct cpudl *cp, int idx)
>   cpudl_heapify_down(cp, idx);
>  }
>  
> -static inline int cpudl_maximum(struct cpudl *cp)
> +static inline int cpudl_maximum_cpu(struct cpudl *cp)
>  {
>   return cp->elements[0].cpu;
>  }
>  
> +static inline u64 cpudl_maximum_dl(struct cpudl *cp)
> +{
> + return cp->elements[0].dl;
> +}
> +
>  /*
>   * cpudl_find - find the best (later-dl) CPU in the system
>   * @cp: the cpudl max-heap context
> @@ -130,11 +135,11 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p,
>   cpumask_and(later_mask, cp->free_cpus, >cpus_allowed)) {
>   return 1;
>   } else {
> - int best_cpu = cpudl_maximum(cp);
> + int best_cpu = cpudl_maximum_cpu(cp);
>   WARN_ON(best_cpu != -1 && !cpu_present(best_cpu));
>  
>   if (cpumask_test_cpu(best_cpu, >cpus_allowed) &&
> - dl_time_before(dl_se->deadline, cp->elements[0].dl)) {
> + dl_time_before(dl_se->deadline, cpudl_maximum_dl(cp))) {
>   if (later_mask)
>   cpumask_set_cpu(best_cpu, later_mask);
>  
> -- 
> 1.9.1


Re: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up

2017-12-21 Thread Byungchul Park
On Tue, Dec 19, 2017 at 10:19:23AM +0900, Byungchul Park wrote:
> Changes from v2
>  - Run spellchecker over the text and fix typos
>  - Add acked-by Daniel
> 
> Changes from v1
>  - Enhance commit msg
>  - Prevent WARN in cpumask_test_cpu() in cpudl_find() when best_cpu == -1

Hello, shall I stop sending this? Let me know if so.

> -8<-
> >From 7735382d07ae6a61d740ae39ba2ecf169d43b8a2 Mon Sep 17 00:00:00 2001
> From: Byungchul Park 
> Date: Wed, 22 Mar 2017 14:25:56 +0900
> Subject: [RESEND PATCH v3 1/2] sched/deadline: Add cpudl_maximum_dl() for 
> clean-up
> 
> Current code uses cpudl_maximum() to get the root node's cpu, while it
> directly accesses the root node like 'cp->elements[0].dl' to get the
> root node's dl. It would be more readable to add a function for the dl,
> as well. Added it.
> 
> Signed-off-by: Byungchul Park 
> Acked-by: Steven Rostedt (VMware) 
> Acked-by: Daniel Bristot de Oliveira 
> ---
>  kernel/sched/cpudeadline.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
> index 8d9562d..9f02035 100644
> --- a/kernel/sched/cpudeadline.c
> +++ b/kernel/sched/cpudeadline.c
> @@ -108,11 +108,16 @@ static void cpudl_heapify(struct cpudl *cp, int idx)
>   cpudl_heapify_down(cp, idx);
>  }
>  
> -static inline int cpudl_maximum(struct cpudl *cp)
> +static inline int cpudl_maximum_cpu(struct cpudl *cp)
>  {
>   return cp->elements[0].cpu;
>  }
>  
> +static inline u64 cpudl_maximum_dl(struct cpudl *cp)
> +{
> + return cp->elements[0].dl;
> +}
> +
>  /*
>   * cpudl_find - find the best (later-dl) CPU in the system
>   * @cp: the cpudl max-heap context
> @@ -130,11 +135,11 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p,
>   cpumask_and(later_mask, cp->free_cpus, >cpus_allowed)) {
>   return 1;
>   } else {
> - int best_cpu = cpudl_maximum(cp);
> + int best_cpu = cpudl_maximum_cpu(cp);
>   WARN_ON(best_cpu != -1 && !cpu_present(best_cpu));
>  
>   if (cpumask_test_cpu(best_cpu, >cpus_allowed) &&
> - dl_time_before(dl_se->deadline, cp->elements[0].dl)) {
> + dl_time_before(dl_se->deadline, cpudl_maximum_dl(cp))) {
>   if (later_mask)
>   cpumask_set_cpu(best_cpu, later_mask);
>  
> -- 
> 1.9.1