linux-kernel - [RFC PATCH 0/4] sched: Disabled LB

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 for Android: free password hash cracker in your pocket

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

Message-Id: <1371761141-25386-1-git-send-email-fweisbec@gmail.com>
Date:	Thu, 20 Jun 2013 22:45:37 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	Li Zhong <zhong@...ux.vnet.ibm.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Borislav Petkov <bp@...en8.de>, Alex Shi <alex.shi@...el.com>,
	Paul Turner <pjt@...gle.com>, Mike Galbraith <efault@....de>,
	Vincent Guittot <vincent.guittot@...aro.org>
Subject: [RFC PATCH 0/4] sched: Disabled LB_BIAS with full dynticks

Hi,

So I've been looking at update_cpu_load_active(),
update_idle_cpu_load() and update_cpu_load_nohz() to
conclude that dynticks are well handled by decay_load_missed()
which catch up with the missed nohz load.

However decay_load_missed() seem to always assume that the nohz
load was zero. So it works well for dynticks idle but it doesn't
seem to fit well for full dynticks. (My understanding of the maths involved
in decay_load_missed might be wrong though, so correct me if
I brainfarted).

Moreover even if we had a mathematical solution to catch up with
full dynticks load like decay_load_missed() does for dynticks idle, we
would need to be able to perform the update from remote readers such as
source_load() or target_load(), which is another problem on its own.

So this patchset propose a simple solution as a start: disable LB_BIAS
sched feature in full dynticks. LB_BIAS is the only user of these
decayed cpu load stats.

LB_BIAS sched feature is quite an obfuscated feature though
so I'm not sure about all the implication of that. It seems to
be about the selection of CPU targets from the different enqueuing
places that each have a different timeslice zooming weight while observing
a target load. And that weight influence the CPU selection.

May be for HPC loads that run only one task per CPU it doesn't matter
much. But some other workloads may suffer from that, especially when
full dynticks will be usable when more than a single task compete on
the CPUs.

Anyway at least this patchset can help starting a discussion.

Those who want to play can fetch from:

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
	sched/core

Thanks,
	Frederic
---

Frederic Weisbecker (4):
      sched: Disable lb_bias feature for full dynticks
      sched: Consolidate nohz cpu load prelude code
      sched: Conditionally build decaying cpu load stats
      sched: Consolidate open coded preemptible() checks

 kernel/context_tracking.c |    3 +-
 kernel/sched/core.c       |    4 +--
 kernel/sched/fair.c       |   13 ++++++-
 kernel/sched/features.h   |    3 ++
 kernel/sched/proc.c       |   75 ++++++++++++++++++++++-----------------------
 kernel/sched/sched.h      |    4 ++
 6 files changed, 57 insertions(+), 45 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/