linux-kernel - [RFC PATCH 0/3] sched: Instrument sched domain flags

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-next>] [day] [month] [year] [list]

Message-Id: <20200311183320.19186-1-valentin.schneider@arm.com>
Date:   Wed, 11 Mar 2020 18:33:17 +0000
From:   Valentin Schneider <valentin.schneider@....com>
To:     linux-kernel@...r.kernel.org
Cc:     mingo@...nel.org, peterz@...radead.org, vincent.guittot@...aro.org,
        dietmar.eggemann@....com, morten.rasmussen@....com
Subject: [RFC PATCH 0/3] sched: Instrument sched domain flags

Hi,

I've repeatedly stared at an SD flag and asked myself "how should that be
set up in the domain hierarchy anyway?". I figured that if we formalize our
flags zoology a bit, we could also do some runtime assertions on them -
this is what this series is all about.

Note that this is based on top of my select_task_rq() series [1], since it
removes SD_LOAD_BALANCE. If that other series dies I can go and rebase this
again on a branch that still has the flag.

Patches
=======

The idea is to associate the flags with a metatype that describes how they
should be set in a sched domain hierarchy - details are in the comments and
commit logs. For now it's just a simple parent/children relationship
description ("if this SD has it, all its {parents, children} have it").

The good thing is that this all goes away when CONFIG_SCHED_DEBUG isn't
set. The bad thing is that replaces SD_* flags definitions with some
unsavoury macros. This is mainly because I wanted to avoid having to
duplicate work between declaring the flags and declaring their types.

Discussion points
=================

I've gone with a flags field so that several behaviours can be associated
with a given SD flag, but right now they only get assigned one. An enum
could fit that job, although it's more constraining.

Naming is also a pain. I'm not really hot on "shared", but that's as
explicit as I managed to be.

I've inserted the reasoning behind the metaflag assignment in
comments. They might be a bit too wordy, so we may want to make them a bit
more broad to lessen the maintenance burden.

Lastly, since this adds an infrastructure to store flag names, we could use
that to pretty-print /proc/sys/kernel/sched_domain/cpu*/domain*/flags.

Some deltas
===========

I get a small codesize increase with SCHED_DEBUG=n due to the first
patch:

$ compare.sh before after vmlinux.o
SYMBOL                   BEFORE     AFTER  DELTA
build_sched_domains      4552       4588   +36

For instance, while my baseline would have this (this is all in sd_init()):

0078    a90c8:	d63f0000 	blr	x0
007c    a90cc:	1284b801 	mov	w1, #0xffffda3f // ~TOPOLOGY_SD_FLAGS
0080    a90d0:	6a010001 	ands	w1, w0, w1
0084    a90d4:	54000c81 	b.ne	a9264 <sd_init+0x214>

The change would have this:

0078    a90c8:	d63f0000 	blr	x0
007c    a90cc:	2a0003e1	mov	w1, w0
0080    a90d0:	1284b800	mov	w0, #0xffffda3f // ~TOPOLOGY_SD_FLAGS
0084    a90d4:	6a00003f	tst	w1, w0
0088    a90d8:	54000c81	b.ne	a9268 <sd_init+0x218>

Sadly, the exact reasons why elude me.

[1]: https://lore.kernel.org/lkml/20200311181601.18314-1-valentin.schneider@arm.com/

Valentin Schneider (3):
  sched/topology: Split out SD_* flags declaration to its own file
  sched/topology: Define and assign sched_domain flag metadata
  sched/topology: Verify SD_* flags setup when sched_debug is on

 include/linux/sched/sd_flags.h | 139 +++++++++++++++++++++++++++++++++
 include/linux/sched/topology.h |  29 +++----
 kernel/sched/topology.c        |  16 ++++
 3 files changed, 170 insertions(+), 14 deletions(-)
 create mode 100644 include/linux/sched/sd_flags.h

--
2.24.0