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

From	Byungchul Park <byungchul.park@lge.com>
Newsgroups	linux.kernel
Subject	Re: [PATCH v6 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()
Date	2017-08-16 04:20 +0200
Message-ID	<ueW66-17t-13@gated-at.bofh.it> (permalink)
References	<ubHmV-2YE-7@gated-at.bofh.it> <ubHmW-2YE-17@gated-at.bofh.it> <ueLNo-2Xb-7@gated-at.bofh.it> <ueUxk-8pZ-23@gated-at.bofh.it> <ueVD3-B6-5@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

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

Thread

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

csiph-web