[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180209123704.GN25201@hirez.programming.kicks-ass.net>
Date: Fri, 9 Feb 2018 13:37:04 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Joel Fernandes <joelaf@...gle.com>
Cc: Rohit Jain <rohit.k.jain@...cle.com>,
Ingo Molnar <mingo@...hat.com>,
LKML <linux-kernel@...r.kernel.org>, steven.sistare@...cle.com,
dhaval.giani@...cle.com,
Dietmar Eggemann <dietmar.eggemann@....com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Morten Rasmussen <morten.rasmussen@....com>,
"Cc: EAS Dev" <eas-dev@...ts.linaro.org>
Subject: Re: [RESEND PATCH] sched/fair: consider RT/IRQ pressure in
select_idle_sibling
On Mon, Feb 05, 2018 at 10:50:41PM -0800, Joel Fernandes wrote:
> That's Ok with me. Just that I remember Peter messing with this path
> and that it was expensive to scan too much for some systems. The other
> thing is you're really doing to do a "fail safe" as you call it search
> here with SIS_PROP set. Do you see a difference in perf when doing the
> same approach as you took in select_idle_core?
>
> Peter, are you with the approach Rohit has adopted to pick best
> capacity idle CPU in select_idle_cpu? I guess nr--; will bail out
> early if we have SIS_PROP set, incase the scan cost gets too much but
> then again we might end scanning too few CPUs.
_IF_ you want to consider capacity, I don't think there's much else you
can do. And yes, nr-- might have to save the day more often.
Powered by blists - more mailing lists