[Ksummit-2013-discuss] [ATTEND] Evaluating the existing implementation of the scheduler and the proposed enhancements for the same

[Preeti U Murthy]

I did bring up the below points as additional comments in the reply to
the Power-aware scheduling Kernel summit proposal. Rafael, Peter
Zijlstra and Tony Luck have given valuable inputs for the same. Looking
at the discussions around it, I felt that it would be good to have this
as a separate attend mail, so as to have the points underneath this
topic clearly listed out, and IMO it would be good to have a separate
discussion around this, apart from the discussions around the power
aware aspect of the scheduler.

There have been discussions in the community around enhancing the kernel
scheduler. Few of the topics have been around power efficient
scheduling, improving the scalability of the scheduler and NUMA
scheduling. These topics have gained active pace over the past one year.

Having participated in the discussions of some of these topics, I have
observed a few points. I am interested in using the Kernel summit as a
platform to discuss these issues.

The recent discussions in scheduler have been around using the
per-entity load tracking metric in load balancing. One of the
discussions that I had around this can be found here:
https://lkml.org/lkml/2013/1/1/89

While working on this issue, I noticed that, if we intend to observe the
behaviour of the scheduler with some clarity, we would have to restrict
the total number of cpus to very few. Else it is hard to understand how
the scheduler is behaving. Besides,*how* do we evaluate the behaviour of
the scheduler to a satisfying extent ?  What are the primary benchmarks
to run? Since the scheduler cannot get it all right, there must be some
primary benchmarks whose performance we must care about most and effort
should be to make sure scheduling works in the favour of their
performance, and that should be good enough.

While working on the power aware scheduler, I was trying to evaluate the
patches posted by Alex Shi.
https://lkml.org/lkml/2013/4/1/133
https://lkml.org/lkml/2013/5/17/72

I was focussing on seeing if consolidation to fewer sockets was
happening via the idle cpu time statistics in /proc/schedstats and then
looking at the output of the benchmarks. While the former observed the
behaviour of the patchset, the latter the performance impact of such a
consolidation. But what other aspects of such enhancements should we be
evaluating?

Currently discussions have been going around integrating scheduler with
cpu frequency and cpuidle subsystem so as to have all the power
management features in one place.
https://lkml.org/lkml/2013/5/30/257.
One of the Kernel summit proposals is around this too. I believe in this
discussion we need to focus on evaluating the existing implementation of
having three different sub systems doing power management.
Also is the best way to evaluate the existing implementation of the
scheduler, from a design point of view alone?

I would be very glad if the core scheduler maintainers participate in
this discussion, so as to guide some of us working towards scheduler
enhancement. Agreed that this discussion is scheduler centric, but the
enhancements proposed for the scheduler have been in varied areas. While
the points mentioned above raise concerns on evaluating the existing
implementation of the scheduler, we also need to be able to evaluate the
interaction between the enhancements being proposed currently for the
scheduler.
   How does having a unified scheduler+cpuidle+cpufrequency subsystem
affect NUMA scheduling? Have the current proposals for enhancing the
scalability of scheduler considered both these changes?  While
discussions around each are happening on independent threads, they are
not coming together anywhere, and some of the developers involved in one
do not overlap with the other.

It is at this time of so much activity and newer scheduler developers
entering the arena that we most need the guidance of scheduler
maintainers and the active scheduler developers to come together to
discuss these issues.

Regards
Preeti U Murthy