[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181031191459.GA3141@hirez.programming.kicks-ass.net>
Date: Wed, 31 Oct 2018 20:14:59 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Valentin Schneider <valentin.schneider@....com>
Cc: Steven Sistare <steven.sistare@...cle.com>, mingo@...hat.com,
subhra.mazumdar@...cle.com, dhaval.giani@...cle.com,
rohit.k.jain@...cle.com, daniel.m.jordan@...cle.com,
pavel.tatashin@...rosoft.com, matt@...eblueprint.co.uk,
umgwanakikbuti@...il.com, riel@...hat.com, jbacik@...com,
juri.lelli@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 07/10] sched/fair: Provide can_migrate_task_llc
On Mon, Oct 29, 2018 at 07:34:50PM +0000, Valentin Schneider wrote:
> On a sidenote, I find it a bit odd that the exec_start threshold depends on
> sysctl_sched_migration_cost, which to me is more about idle_balance() cost
> than "how long does it take for a previously run task to go cache cold".
A long long (think 2.6.20 long ago) there was code that did boot-time
measurement of the various cache topology costs and that threshold was
related to that.
That code got killed because of boot to boot variance and dubious
benefits.
The migration cost is what it was replaced with as a single measure.
migration cost was then later abused in the newidle balance because it
was over eager. Ideally we'd get rid of it there, because we've now got
that much more elaborate accounting, but Rohit tried and found some
regression because of that.
Maybe we should remove it from newidle anyway.
Powered by blists - more mailing lists