* Rakib Mullick <rakib.mull...@gmail.com> wrote:
> On Fri, Apr 19, 2013 at 2:25 PM, Ingo Molnar <mi...@kernel.org> wrote:
> >
> > * Paul Gortmaker <paul.gortma...@windriver.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.gortma...@windriver.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.
> >
> Well, kernel/sched/stat.c - also exposes scheduler ABI to userspace.
schedstats is more like a debug API, used by a low number of tools.
So I don't think it's particularly confusing.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
