Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Mathieu Desnoyers <mathieu.desnoyers <at> efficios.com>
Subject: [RFC PATCH 00/11] sched: CFS low-latency features
Newsgroups: gmane.linux.kernel
Date: Thursday 26th August 2010 18:09:08 UTC (over 6 years ago)
Hi,

Following the findings I presented a few months ago
(http://lkml.org/lkml/2010/4/18/13)
about CFS having large vruntime spread
issues, Peter Zijlstra and I pursued the discussion and the implementation
effort (my work on this is funded by Nokia). I recently put the result
together
and came up with this patchset, combining both his work and mine.

With this patchset, I got the following results with wakeup-latency.c (a
10ms
periodic timer), running periodic-fork.sh, Xorg, make -j3 and firefox
(playing a
youtube video), with Xorg moving terminal windows around, in parallel on a
UP
system (links to the test program source in the dyn min_vruntime patch).
The
Xorg interactivity is very good with the new features enabled, but was poor
originally with the vanilla mainline scheduler. The 10ms timer delays are
as
follow:

                         2.6.35.2 mainline*   with low-latency features**
maximum latency:                34465.2 µs                    8261.4
µs
average latency:                 6445.5 µs                     211.2
µs
missed timer events:                yes                           no

* 2.6.35.2 mainline test needs to run periodic-fork.sh for a few minutes
first
  to let it rip the spread apart.

** low-latency features:

with the patchset applied and CONFIG_SCHED_DEBUG=y
(with debugfs mounted in /sys/debugfs)

for opt in DYN_MIN_VRUNTIME \
        NO_FAIR_SLEEPERS FAIR_SLEEPERS_INTERACTIVE FAIR_SLEEPERS_TIMER \
        INTERACTIVE TIMER \
        INTERACTIVE_FORK_EXPEDITED TIMER_FORK_EXPEDITED;
do echo $opt > /sys/debugfs/sched_features;
done

These patches are designed to allow individual enabling of each feature and
to
make sure that the object size of sched.o does not grow when the features
are
disabled on a CONFIG_SCHED_DEBUG=n kernel. Optimization of the
try_to_wake_up()
fast path when features are enabled could be done later by merging some of
these
features together. This patchset is based on 2.6.35.2.

Feedback is welcome,

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
 
CD: 47ms