Re: [PATCH v6 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()
On Wed, 16 Aug 2017 23:04:14 +0900 Byungchul Park wrote: > On Wed, Aug 16, 2017 at 09:32:44AM -0400, Steven Rostedt wrote: > > On Wed, 16 Aug 2017 11:17:36 +0900 > > Byungchul Park wrote: > > > > > > > Yes, that's what I intended. IOW: > > > > > > If (we found a proper sd, not having SD_PREFER_SIBLING?) > > > use the sd; > > > else if (we found a proper sd, having SD_PREFER_SIBLING?) > > > use the smallest sd among SD_PREFER_SIBLING sds; > > > > BTW, what do you mean by "smallest sd"? > > There might be more than one SD_PREFER_SIBLING domain in its hierachy. > In that case, we have to choose one of them. Imagine the following > example, in case that the source cpu is cpu 0: > > [Domain hierachy for cpu 0] > > cpu 0 -+ domain 1 -+ >| SD_PREFER_SIBLING flaged | > cpu 1 -+ +- domain 2 >| SD_PREFER_SIBLING flaged > cpu 2 -+---+ >| > cpu 3 -+ > > In this case, we have to choose domain 1 than 2, because cpus in domain 1 > are closer to the source cpu, cpu 0. That's what I meant. Then you mean "closest sd", at least that makes more sense in the context. -- Steve
Re: [PATCH v6 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()
On Wed, Aug 16, 2017 at 09:32:44AM -0400, Steven Rostedt wrote: > On Wed, 16 Aug 2017 11:17:36 +0900 > Byungchul Park wrote: > > > > Yes, that's what I intended. IOW: > > > > If (we found a proper sd, not having SD_PREFER_SIBLING?) > > use the sd; > > else if (we found a proper sd, having SD_PREFER_SIBLING?) > > use the smallest sd among SD_PREFER_SIBLING sds; > > BTW, what do you mean by "smallest sd"? There might be more than one SD_PREFER_SIBLING domain in its hierachy. In that case, we have to choose one of them. Imagine the following example, in case that the source cpu is cpu 0: [Domain hierachy for cpu 0] cpu 0 -+ domain 1 -+ | SD_PREFER_SIBLING flaged | cpu 1 -+ +- domain 2 | SD_PREFER_SIBLING flaged cpu 2 -+---+ | cpu 3 -+ In this case, we have to choose domain 1 than 2, because cpus in domain 1 are closer to the source cpu, cpu 0. That's what I meant.
Re: [PATCH v6 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()
On Wed, 16 Aug 2017 11:17:36 +0900 Byungchul Park wrote: > Yes, that's what I intended. IOW: > > If (we found a proper sd, not having SD_PREFER_SIBLING?) > use the sd; > else if (we found a proper sd, having SD_PREFER_SIBLING?) > use the smallest sd among SD_PREFER_SIBLING sds; BTW, what do you mean by "smallest sd"? -- Steve
Re: [PATCH v6 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()
On Tue, Aug 15, 2017 at 09:42:01PM -0400, Steven Rostedt wrote:
> > > > @@ -1385,6 +1407,17 @@ static int find_later_rq(struct task_struct
> > > > *task)
> > > > * already under consideration through
> > > > later_mask.
> > > > */
> > > > if (best_cpu < nr_cpu_ids) {
> > > > + /*
> > > > +* If current domain is
> > > > SD_PREFER_SIBLING
> > > > +* flaged, we have to get more chances
> > > > to
> > > > +* check other siblings.
>
> BTW, "we have to get more chances" doesn't really make sense. Do you
> mean "we need to try other domains"?
Yes, we need to try other domains first if current domain is
SD_PREFER_SIBLING flaged.
> > > > +*/
> > > > + if (sd->flags & SD_PREFER_SIBLING) {
> > > > + prefer = sd;
> > >
> > > Is this how the SD_PREFER_SIBLING works? According to this, the
> > > preferred sd is the next sd in for_each_domain(). Not to mention, the
> > > prefer variable stays set if the next domain has no available CPUs. Is
> > > that what we want?
> >
> > Maybe I don't understand what you want to say. The variable, prefer, is
> > used to pick up the smallest sched domain among SD_PREFER_SIBLING
> > domains, if more than one SD_PREFER_SIBLING domain exist in the visit.
> >
> > The prefer variable alway points to the previous SD_PREFER_SIBLING domain.
> > And that must stay set to be used as a fallback choise if the next domain
> > has no available CPUs.
> >
> > Could you explain what I mis-understand?
> >
>
> I may be the one confused here ;-)
>
> I think I misread the patch. So, the SD_PREFER_SIBLING means to try to
> find a CPU in another sd instead? Thus, we try to find a CPU in a sd
> that does not have SD_PREFER_SIBLING set. And if there is none, we use
> the preferred sd as a fallback. Is that correct?
Yes, that's what I intended. IOW:
If (we found a proper sd, not having SD_PREFER_SIBLING?)
use the sd;
else if (we found a proper sd, having SD_PREFER_SIBLING?)
use the smallest sd among SD_PREFER_SIBLING sds;
Thanks,
Byungchul
Re: [PATCH v6 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()
On Wed, 16 Aug 2017 09:38:11 +0900
Byungchul Park wrote:
> On Tue, Aug 15, 2017 at 11:19:40AM -0400, Steven Rostedt wrote:
> > > @@ -1385,6 +1407,17 @@ static int find_later_rq(struct task_struct *task)
> > >* already under consideration through later_mask.
> > >*/
> > > if (best_cpu < nr_cpu_ids) {
> > > + /*
> > > + * If current domain is SD_PREFER_SIBLING
> > > + * flaged, we have to get more chances to
> > > + * check other siblings.
BTW, "we have to get more chances" doesn't really make sense. Do you
mean "we need to try other domains"?
> > > + */
> > > + if (sd->flags & SD_PREFER_SIBLING) {
> > > + prefer = sd;
> >
> > Is this how the SD_PREFER_SIBLING works? According to this, the
> > preferred sd is the next sd in for_each_domain(). Not to mention, the
> > prefer variable stays set if the next domain has no available CPUs. Is
> > that what we want?
>
> Maybe I don't understand what you want to say. The variable, prefer, is
> used to pick up the smallest sched domain among SD_PREFER_SIBLING
> domains, if more than one SD_PREFER_SIBLING domain exist in the visit.
>
> The prefer variable alway points to the previous SD_PREFER_SIBLING domain.
> And that must stay set to be used as a fallback choise if the next domain
> has no available CPUs.
>
> Could you explain what I mis-understand?
>
I may be the one confused here ;-)
I think I misread the patch. So, the SD_PREFER_SIBLING means to try to
find a CPU in another sd instead? Thus, we try to find a CPU in a sd
that does not have SD_PREFER_SIBLING set. And if there is none, we use
the preferred sd as a fallback. Is that correct?
I'm not familiar with the SD_PREFER_SIBLING flag, the only
documentation I can find about it is the comment that states:
/* Prefer to place tasks in a sibling domain */
And the very informative git commit change log:
commit b5d978e0c7e79a7ff842e895c85a86b38c71f1cd
Date: Tue Sep 1 10:34:33 2009 +0200
sched: Add SD_PREFER_SIBLING
Do the placement thing using SD flags.
;-)
-- Steve
Re: [PATCH v6 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()
On Tue, Aug 15, 2017 at 11:19:40AM -0400, Steven Rostedt wrote:
> > @@ -1385,6 +1407,17 @@ static int find_later_rq(struct task_struct *task)
> > * already under consideration through later_mask.
> > */
> > if (best_cpu < nr_cpu_ids) {
> > + /*
> > +* If current domain is SD_PREFER_SIBLING
> > +* flaged, we have to get more chances to
> > +* check other siblings.
> > +*/
> > + if (sd->flags & SD_PREFER_SIBLING) {
> > + prefer = sd;
>
> Is this how the SD_PREFER_SIBLING works? According to this, the
> preferred sd is the next sd in for_each_domain(). Not to mention, the
> prefer variable stays set if the next domain has no available CPUs. Is
> that what we want?
Maybe I don't understand what you want to say. The variable, prefer, is
used to pick up the smallest sched domain among SD_PREFER_SIBLING
domains, if more than one SD_PREFER_SIBLING domain exist in the visit.
The prefer variable alway points to the previous SD_PREFER_SIBLING domain.
And that must stay set to be used as a fallback choise if the next domain
has no available CPUs.
Could you explain what I mis-understand?
Thanks,
Byungchul
> -- Steve
>
>
> > + if (fallback_cpu == -1)
> > + fallback_cpu = best_cpu;
> > + continue;
> > + }
> > rcu_read_unlock();
> > return best_cpu;
> > }
> > @@ -1393,6 +1426,13 @@ static int find_later_rq(struct task_struct *task)
> > rcu_read_unlock();
> >
> > /*
> > +* If fallback_cpu is valid, all our guesses failed *except* for
> > +* SD_PREFER_SIBLING domain. Now, we can return the fallback cpu.
> > +*/
> > + if (fallback_cpu != -1)
> > + return fallback_cpu;
> > +
> > + /*
> > * At this point, all our guesses failed, we just return
> > * 'something', and let the caller sort the things out.
> > */
Re: [PATCH v6 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()
On Mon, 7 Aug 2017 12:50:33 +0900
Byungchul Park wrote:
> It would be better to avoid pushing tasks to other cpu within
> a SD_PREFER_SIBLING domain, instead, get more chances to check other
> siblings.
>
> Signed-off-by: Byungchul Park
> ---
> kernel/sched/deadline.c | 46 +++---
> 1 file changed, 43 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 0223694..2fd1591 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -1319,12 +1319,35 @@ static struct task_struct
> *pick_earliest_pushable_dl_task(struct rq *rq, int cpu
>
> static DEFINE_PER_CPU(cpumask_var_t, local_cpu_mask_dl);
>
> +/*
> + * Find the first cpu in: mask & sd & ~prefer
> + */
> +static int find_cpu(const struct cpumask *mask,
> + const struct sched_domain *sd,
> + const struct sched_domain *prefer)
> +{
> + const struct cpumask *sds = sched_domain_span(sd);
> + const struct cpumask *ps = prefer ? sched_domain_span(prefer) : NULL;
> + int cpu = -1;
> +
> + while ((cpu = cpumask_next(cpu, mask)) < nr_cpu_ids) {
> + if (!cpumask_test_cpu(cpu, sds))
> + continue;
> + if (ps && cpumask_test_cpu(cpu, ps))
> + continue;
> + break;
> + }
> +
> + return cpu;
> +}
> +
> static int find_later_rq(struct task_struct *task)
> {
> - struct sched_domain *sd;
> + struct sched_domain *sd, *prefer = NULL;
> struct cpumask *later_mask =
> this_cpu_cpumask_var_ptr(local_cpu_mask_dl);
> int this_cpu = smp_processor_id();
> int cpu = task_cpu(task);
> + int fallback_cpu = -1;
>
> /* Make sure the mask is initialized first */
> if (unlikely(!later_mask))
> @@ -1376,8 +1399,7 @@ static int find_later_rq(struct task_struct *task)
> return this_cpu;
> }
>
> - best_cpu = cpumask_first_and(later_mask,
> - sched_domain_span(sd));
> + best_cpu = find_cpu(later_mask, sd, prefer);
> /*
>* Last chance: if a cpu being in both later_mask
>* and current sd span is valid, that becomes our
> @@ -1385,6 +1407,17 @@ static int find_later_rq(struct task_struct *task)
>* already under consideration through later_mask.
>*/
> if (best_cpu < nr_cpu_ids) {
> + /*
> + * If current domain is SD_PREFER_SIBLING
> + * flaged, we have to get more chances to
> + * check other siblings.
> + */
> + if (sd->flags & SD_PREFER_SIBLING) {
> + prefer = sd;
Is this how the SD_PREFER_SIBLING works? According to this, the
preferred sd is the next sd in for_each_domain(). Not to mention, the
prefer variable stays set if the next domain has no available CPUs. Is
that what we want?
-- Steve
> + if (fallback_cpu == -1)
> + fallback_cpu = best_cpu;
> + continue;
> + }
> rcu_read_unlock();
> return best_cpu;
> }
> @@ -1393,6 +1426,13 @@ static int find_later_rq(struct task_struct *task)
> rcu_read_unlock();
>
> /*
> + * If fallback_cpu is valid, all our guesses failed *except* for
> + * SD_PREFER_SIBLING domain. Now, we can return the fallback cpu.
> + */
> + if (fallback_cpu != -1)
> + return fallback_cpu;
> +
> + /*
>* At this point, all our guesses failed, we just return
>* 'something', and let the caller sort the things out.
>*/
[PATCH v6 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()
It would be better to avoid pushing tasks to other cpu within
a SD_PREFER_SIBLING domain, instead, get more chances to check other
siblings.
Signed-off-by: Byungchul Park
---
kernel/sched/deadline.c | 46 +++---
1 file changed, 43 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 0223694..2fd1591 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1319,12 +1319,35 @@ static struct task_struct
*pick_earliest_pushable_dl_task(struct rq *rq, int cpu
static DEFINE_PER_CPU(cpumask_var_t, local_cpu_mask_dl);
+/*
+ * Find the first cpu in: mask & sd & ~prefer
+ */
+static int find_cpu(const struct cpumask *mask,
+ const struct sched_domain *sd,
+ const struct sched_domain *prefer)
+{
+ const struct cpumask *sds = sched_domain_span(sd);
+ const struct cpumask *ps = prefer ? sched_domain_span(prefer) : NULL;
+ int cpu = -1;
+
+ while ((cpu = cpumask_next(cpu, mask)) < nr_cpu_ids) {
+ if (!cpumask_test_cpu(cpu, sds))
+ continue;
+ if (ps && cpumask_test_cpu(cpu, ps))
+ continue;
+ break;
+ }
+
+ return cpu;
+}
+
static int find_later_rq(struct task_struct *task)
{
- struct sched_domain *sd;
+ struct sched_domain *sd, *prefer = NULL;
struct cpumask *later_mask =
this_cpu_cpumask_var_ptr(local_cpu_mask_dl);
int this_cpu = smp_processor_id();
int cpu = task_cpu(task);
+ int fallback_cpu = -1;
/* Make sure the mask is initialized first */
if (unlikely(!later_mask))
@@ -1376,8 +1399,7 @@ static int find_later_rq(struct task_struct *task)
return this_cpu;
}
- best_cpu = cpumask_first_and(later_mask,
- sched_domain_span(sd));
+ best_cpu = find_cpu(later_mask, sd, prefer);
/*
* Last chance: if a cpu being in both later_mask
* and current sd span is valid, that becomes our
@@ -1385,6 +1407,17 @@ static int find_later_rq(struct task_struct *task)
* already under consideration through later_mask.
*/
if (best_cpu < nr_cpu_ids) {
+ /*
+* If current domain is SD_PREFER_SIBLING
+* flaged, we have to get more chances to
+* check other siblings.
+*/
+ if (sd->flags & SD_PREFER_SIBLING) {
+ prefer = sd;
+ if (fallback_cpu == -1)
+ fallback_cpu = best_cpu;
+ continue;
+ }
rcu_read_unlock();
return best_cpu;
}
@@ -1393,6 +1426,13 @@ static int find_later_rq(struct task_struct *task)
rcu_read_unlock();
/*
+* If fallback_cpu is valid, all our guesses failed *except* for
+* SD_PREFER_SIBLING domain. Now, we can return the fallback cpu.
+*/
+ if (fallback_cpu != -1)
+ return fallback_cpu;
+
+ /*
* At this point, all our guesses failed, we just return
* 'something', and let the caller sort the things out.
*/
--
1.9.1
