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
| ||
|
Date: Fri, 19 Apr 2013 10:25:46 +0200 From: Ingo Molnar <mingo@...nel.org> To: Paul Gortmaker <paul.gortmaker@...driver.com> Cc: Peter Zijlstra <peterz@...radead.org>, Thomas Gleixner <tglx@...utronix.de>, Frederic Weisbecker <fweisbec@...il.com>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [RFC PATCH 0/2] sched: move content out of core files for load average * Paul Gortmaker <paul.gortmaker@...driver.com> wrote: > On 13-04-18 07:14 AM, Peter Zijlstra wrote: > > On Mon, 2013-04-15 at 11:33 +0200, Ingo Molnar wrote: > >> * Paul Gortmaker <paul.gortmaker@...driver.com> wrote: > >> > >>> Recent activity has had a focus on moving functionally related blocks of stuff > >>> out of sched/core.c into stand-alone files. The code relating to load average > >>> calculations has grown significantly enough recently to warrant placing it in a > >>> separate file. > >>> > >>> Here we do that, and in doing so, we shed ~20k of code from sched/core.c (~10%). > >>> > >>> A couple small static functions in the core sched.h header were also localized > >>> to their singular user in sched/fair.c at the same time, with the goal to also > >>> reduce the amount of "broadcast" content in that sched.h file. > >> > >> Nice! > >> > >> Peter, is this (and the naming of the new file) fine with you too? > > > > Yes and no.. that is I do like the change, but I don't like the > > filename. We have _waaaay_ too many different things we call load_avg. > > > > That said, I'm having a somewhat hard time coming up with a coherent > > alternative :/ > > Several of the relocated functions start their name with "calc_load..." > Does "calc_load.c" sound any better? Peter has a point about load_avg being somewhat of a misnomer: that's not your fault in any way, we created overlapping naming within the scheduler and are now hurting from it. Here are the main scheduler 'load' concepts we have right now: - The externally visible 'average load' value extracted by tools like 'top' via /proc/loadavg and handled by fs/proc/loadavg.c. Internally the naming is all over the map: the fields that are updated are named 'avenrun[]', most other variables and methods are named calc_load_*(), and a few callbacks are named *_cpu_load_*(). - rq->cpu_load, a weighted, vectored scheduler-internal notion of task load average with multiple run length averages. Only exposed by debug interfaces but otherwise relied on by the scheduler for SMP load balancing. - se->avg - per entity (per task) load average. This is integrated differently from the cpu_load - but work is ongoing to possibly integrate it with the rq->cpu_load metric. This metric is used for CPU internal execution time allocation and timeslicing, based on nice value priorities and cgroup weights and constraints. Work is ongoing to integrate rq->cpu_load and se->avg - eventually they will become one metric. It might eventually make sense to integrate the 'average load' calculation as well with all this - as they really have a similar purpose, the avenload[] vector of averages is conceptually similar to the rq->cpu_load[] vector of averages. So I'd suggest to side-step all that existing confusion and simply name the new file kernel/sched/proc.c - our external /proc scheduler ABI towards userspace. This is similar to the already existing kernel/irq/proc.c pattern. A technical request: mind doing your patch against the tip:master tree? It's at: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master We have changes pending both in the sched/core, timers/nohz, core/locking and smp/hotplug trees, and your split-up interacts with all that pending work, creating conflicts. Thanks, Ingo -- 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/
Powered by blists - more mailing lists