All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.