[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170816003810.GO20323@X58A-UD3R>
Date: Wed, 16 Aug 2017 09:38:11 +0900
From: Byungchul Park <byungchul.park@....com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: peterz@...radead.org, mingo@...nel.org,
linux-kernel@...r.kernel.org, juri.lelli@...il.com,
kernel-team@....com
Subject: 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.
> > */
Powered by blists - more mailing lists