From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: dmitry.adamushko@gmail.com, a.p.zijlstra@chello.nl,
dhaval@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
efault@gmx.de, skumar@linux.vnet.ibm.com,
Balbir Singh <balbir@in.ibm.com>, Dipankar <dipankar@in.ibm.com>
Subject: [PATCH 0/4] sched: group scheduler related patches (V3)
Date: Mon, 26 Nov 2007 10:30:44 +0530 [thread overview]
Message-ID: <20071126050044.GA5304@linux.vnet.ibm.com> (raw)
In-Reply-To: <20071119190057.GA12650@elte.hu>
Here's V3 of the group scheduler related patches, which is mainly addressing
improved fairness of cpu bandwidth allocation for task groups.
Patch 1/4 -> coding style cleanup
Patch 2/4 -> Minor group scheduling related bug fixes
Patch 3/4 (v1) -> Modifies how cpu load is calculated, such that there is zero
impact on !CONFIG_FAIR_GROUP_SCHED
Patch 3/4 (v2) -> Modifies how cpu load is calculated, such that there is a
small impact on code size (but should have NO impact on
functionality or runtime behavior) for
!CONFIG_FAIR_GROUP_SCHED case. The resulting code however is
much neater since it avoids some #ifdefs. I prefer v2.
Patch 4/4 -> Updates load balance logic to provide improved fairness for
task groups.
To have zero impact on !CONFIG_FAIR_GROUP_SCHED case, please apply the
following patches:
- Patch 1/4
- Patch 2/4
- Patch 3/4 (v1)
- Patch 4/4
I personally prefer v2 of Patch 3/4. Even though it has a minor impact
on code size for !CONFIG_FAIR_GROUP_SCHED case, the overall code is much
neater IMHO.
Impact on sched.o size:
=======================
!CONFIG_FAIR_GROUP_SCHED:
text data bss dec hex filename
36829 2766 48 39643 9adb sched.o-before-nofgs
36829 2766 48 39643 9adb sched.o-after-v1-nofgs (v1 of Patch 3/4)
36843 2766 48 39657 9ae9 sched.o-after-v2-nofgs (v2 of Patch 3/4)
CONFIG_FAIR_GROUP_SCHED:
text data bss dec hex filename
39019 3346 336 42701 a6cd sched.o-before-fgs
40303 3482 308 44093 ac3d sched.o-after-v1-fgs (v1 of Patch 3/4)
40303 3482 308 44093 ac3d sched.o-after-v2-fgs (v2 of Patch 3/4)
Changes since V2 of this patchset [1]
- Split the patches better and make them pass under checkpatch.pl
script
- Fixed compile issues under different config options and also
a suspend failure (as posted by Ingo at [2])
- Make load_balance_monitor thread run as real-time task,
so that its execution is not limited by shares allocated to
default task group (init_task_group).
- Reduced minimum shares that can be allocated to a group to 1
(from 100). Would be usefull if someone wants a task group
to get very low bandiwdth or get bandwidth only when other groups
are idle.
- Removed check for tg->last_total_load check in rebalance_shares()
(which was incorrect in V2)
Changes since V1 of this patchset [3]:
- Introduced a task_group_mutex to serialize add/removal of task groups (as
pointed by Dipankar)
Please apply if there are no major concerns.
References:
1. http://marc.info/?l=linux-kernel&m=119549585223262
2. http://lkml.org/lkml/2007/11/19/127
3. http://marc.info/?l=linux-kernel&m=119547452517055
--
Regards,
vatsa
next prev parent reply other threads:[~2007-11-26 4:48 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-19 12:27 [PATCH 0/2] sched: Group scheduler related patches Srivatsa Vaddagiri
2007-11-19 12:28 ` [PATCH 1/2] sched: Minor cleanups Srivatsa Vaddagiri
2007-11-19 13:08 ` Ingo Molnar
2007-11-19 15:01 ` Srivatsa Vaddagiri
2007-11-19 12:30 ` [PATCH 2/2] sched: Improve fairness of cpu allocation for task groups Srivatsa Vaddagiri
2007-11-19 13:12 ` Ingo Molnar
2007-11-19 15:03 ` Srivatsa Vaddagiri
2007-11-19 15:22 ` Ingo Molnar
2007-11-19 16:06 ` Srivatsa Vaddagiri
2007-11-19 19:00 ` Ingo Molnar
2007-11-26 5:00 ` Srivatsa Vaddagiri [this message]
2007-11-26 5:02 ` [PATCH 1/4] sched: code cleanup Srivatsa Vaddagiri
2007-11-26 5:03 ` [PATCH 2/4] sched: minor fixes for group scheduler Srivatsa Vaddagiri
2007-11-26 5:05 ` [Patch 3/4 v1] sched: change how cpu load is calculated Srivatsa Vaddagiri
2007-11-26 5:06 ` [Patch 3/4 v2] " Srivatsa Vaddagiri
2007-11-26 5:09 ` [Patch 4/4] sched: Improve fairness of cpu bandwidth allocation for task groups Srivatsa Vaddagiri
2007-11-26 20:28 ` Ingo Molnar
2007-11-27 5:06 ` [Patch 0/5] sched: group scheduler related patches (V4) Srivatsa Vaddagiri
2007-11-27 5:08 ` [Patch 1/5] sched: code cleanup Srivatsa Vaddagiri
2007-11-27 5:09 ` [Patch 2/5] sched: minor fixes for group scheduler Srivatsa Vaddagiri
2007-11-27 5:11 ` [Patch 3/5 v1] sched: change how cpu load is calculated Srivatsa Vaddagiri
2007-11-27 5:12 ` [Patch 3/5 v2] " Srivatsa Vaddagiri
2007-11-27 5:21 ` [Patch 4/5] sched: introduce a mutex and corresponding API to serialize access to doms_cur[] array Srivatsa Vaddagiri
2007-11-27 5:27 ` [Patch 5/5] sched: Improve fairness of cpu bandwidth allocation for task groups Srivatsa Vaddagiri
2007-11-27 11:09 ` [Patch 0/5] sched: group scheduler related patches (V4) Ingo Molnar
2007-11-27 11:42 ` Srivatsa Vaddagiri
2007-11-27 12:53 ` Ingo Molnar
2007-11-27 14:32 ` Srivatsa Vaddagiri
2007-11-26 20:29 ` [Patch 4/4] sched: Improve fairness of cpu bandwidth allocation for task groups Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071126050044.GA5304@linux.vnet.ibm.com \
--to=vatsa@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=balbir@in.ibm.com \
--cc=dhaval@linux.vnet.ibm.com \
--cc=dipankar@in.ibm.com \
--cc=dmitry.adamushko@gmail.com \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=skumar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.