lkml.org 
[lkml]   [2020]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC PATCH 11/13] sched: migration changes for core scheduling
    On Fri, Jun 12, 2020 at 9:21 AM Joel Fernandes <joel@joelfernandes.org> wrote:
    >
    > > +#ifdef CONFIG_SCHED_CORE
    > > + if (available_idle_cpu(cpu) &&
    > > + sched_core_cookie_match(cpu_rq(cpu), p))
    > > + break;
    > > +#else
    >
    > select_idle_cpu() is called only if no idle core could be found in the LLC by
    > select_idle_core().
    >
    > So, would it be better here to just do the cookie equality check directly
    > instead of calling the sched_core_cookie_match() helper? More so, because
    > select_idle_sibling() is a fastpath.
    >
    Agree, this makes sense to me.

    > AFAIR, that's what v4 did:
    >
    > if (available_idle_cpu(cpu))
    > #ifdef CONFIG_SCHED_CORE
    > if (sched_core_enabled(cpu_rq(cpu)) &&
    > (p->core_cookie == cpu_rq(cpu)->core->core_cookie))
    > break;
    > #else
    > break;
    > #endif
    >
    This patch was initially not in v4 and this is a merging of 4 patches
    suggested post-v4. During the initial round, code was like above. But since
    there looked like a code duplication in the different migration paths,
    it was consolidated into sched_core_cookie_match() and it caused this
    extra logic to this specific code path. As you mentioned, I also feel
    we do not need to check for core idleness in this path.

    Thanks,
    Vineeth

    \
     
     \ /
      Last update: 2020-06-12 23:32    [W:3.833 / U:2.248 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site