Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Tejun Heo <tj <at> kernel.org>
Subject: [PATCHSET sched/core] cpuhog: implement and use cpuhog, take#2
Newsgroups: gmane.linux.kernel
Date: Wednesday 17th March 2010 08:40:47 UTC (over 6 years ago)
Hello,

This is the second take of cpuhog patchset which implements a
simplistic cpu monopolization mechanism and reimplements
stop_machine() and replaces migration_thread with it.

This allows stop_machine() to be simpler and much more efficient on
very large machines without using more resources while also making the
rather messy overloaded migration_thread usages cleaner.

This should solve the slow boot problem[1] caused by repeated
stop_machine workqueue creation/destruction reported by Dimitri
Sivanich.

Changes from the last take[L] are

* cpuhog callbacks are no longer allowed to sleep.  preemption is
  disabled around them.

* Patches are rebased on top of sched/core.

This patchset contains the following four patches.

 0001-cpuhog-implement-cpuhog.patch
 0002-stop_machine-reimplement-using-cpuhog.patch
 0003-scheduler-replace-migration_thread-with-cpuhog.patch
 0004-scheduler-kill-paranoia-check-in-synchronize_sched_e.patch

Tested cpu on/offlining, shutdown, all migration usage paths including
RCU torture test at 0003 and 004 and everything seems to work fine
here.

Peter suggested reusing stop_cpu/machine() names instead of
introducing new hog_* names.  While renaming definitely is an option,
I think it's better to keep the distinction between
stop_{cpu|machine}() and this maximum priority scheduler based
monopolization mechanism.

hog_[one_]cpu[s]() schedule highest priority task to monopolize the
upper half of cpu[s] but doesn't affect contextless part of the cpu
(hard/soft irq, bh, tasklet...) nor does it coordinate with each other
to make sure all the cpus are synchronized while executing the
callbacks.  In that sense, it is the lowest bottom of upper half but
not quite stopping the cpu or the machine and I think the distinction
is meaningful to make.  Now that the callbacks are not allowed to
sleep, they really 'hog' the target cpus too.

I wanted to avoid verbs associated with the traditional workqueue -
schedule and queue, while emphasizing that this is something that you
don't want to abuse - so the verb hog.  monopolize_cpu() was the
second choice but hog is shorter and can be used as a noun as-is, so I
chose hog.  If you like/dislike the name, please let me know.

If Rusty and RCU people agree (where are you? :-), I think it would be
the easiest to route the whole thing through sched tree so I rebased
it on top of sched/core.  Again, if you disagree, please let me know.

The tree is available in the following git tree.

  git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git
cpuhog

diffstat follows.

 Documentation/RCU/torture.txt |   10 -
 arch/s390/kernel/time.c       |    1 
 drivers/xen/manage.c          |   14 -
 include/linux/cpuhog.h        |   24 ++
 include/linux/rcutiny.h       |    2 
 include/linux/rcutree.h       |    1 
 include/linux/stop_machine.h  |   20 --
 kernel/Makefile               |    2 
 kernel/cpu.c                  |    8 
 kernel/cpuhog.c               |  368
++++++++++++++++++++++++++++++++++++++++++
 kernel/module.c               |   14 -
 kernel/rcutorture.c           |    2 
 kernel/sched.c                |  282 +++++---------------------------
 kernel/sched_fair.c           |   39 ++--
 kernel/stop_machine.c         |  162 ++++--------------
 15 files changed, 511 insertions(+), 438 deletions(-)

Thanks.

--
tejun

[1] http://thread.gmane.org/gmane.linux.kernel/957726
[L] http://thread.gmane.org/gmane.linux.kernel/958743
 
CD: 3ms