Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1712238 > unrolled thread

Re: [PATCH v6 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v6 1/2] sched/deadline: Add support for  SD_PREFER_SIBLING on find_later_rq() Steven Rostedt <rostedt@goodmis.org> - 2017-08-15 17:20 +0200
    Re: [PATCH v6 1/2] sched/deadline: Add support for SD_PREFER_SIBLING  on find_later_rq() Byungchul Park <byungchul.park@lge.com> - 2017-08-16 02:40 +0200
      Re: [PATCH v6 1/2] sched/deadline: Add support for  SD_PREFER_SIBLING on find_later_rq() Steven Rostedt <rostedt@goodmis.org> - 2017-08-16 03:50 +0200
        Re: [PATCH v6 1/2] sched/deadline: Add support for SD_PREFER_SIBLING  on find_later_rq() Byungchul Park <byungchul.park@lge.com> - 2017-08-16 04:20 +0200
          Re: [PATCH v6 1/2] sched/deadline: Add support for  SD_PREFER_SIBLING on find_later_rq() Steven Rostedt <rostedt@goodmis.org> - 2017-08-16 15:40 +0200
            Re: [PATCH v6 1/2] sched/deadline: Add support for SD_PREFER_SIBLING  on find_later_rq() Byungchul Park <byungchul.park@lge.com> - 2017-08-16 16:10 +0200
              Re: [PATCH v6 1/2] sched/deadline: Add support for  SD_PREFER_SIBLING on find_later_rq() Steven Rostedt <rostedt@goodmis.org> - 2017-08-16 16:30 +0200

#1712238 — 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 <byungchul.park@lge.com> 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 <byungchul.park@lge.com>
> ---
>  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.
>  	 */

[toc] | [next] | [standalone]

#1712554 — 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.
> >  	 */

[toc] | [prev] | [next] | [standalone]

#1712572

On Wed, 16 Aug 2017 09:38:11 +0900
Byungchul Park <byungchul.park@lge.com> 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

[toc] | [prev] | [next] | [standalone]

#1712598 — 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

[toc] | [prev] | [next] | [standalone]

#1712946

On Wed, 16 Aug 2017 11:17:36 +0900
Byungchul Park <byungchul.park@lge.com> 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

[toc] | [prev] | [next] | [standalone]

#1712984 — 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 <byungchul.park@lge.com> 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.

[toc] | [prev] | [next] | [standalone]

#1712997

On Wed, 16 Aug 2017 23:04:14 +0900
Byungchul Park <byungchul.park@lge.com> 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 <byungchul.park@lge.com> 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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web