linux-kernel - Re: [PATCH v6 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 15 Aug 2017 21:42:01 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Byungchul Park <byungchul.park@....com>
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 Wed, 16 Aug 2017 09:38:11 +0900
Byungchul Park <byungchul.park@....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