mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Preeti U Murthy <preeti@linux.vnet.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: peterz@infradead.org, svaidy@linux.vnet.ibm.com, pjt@google.com
Subject: [RFC PATCH 0/2] sched: Load Balancing using Per-entity-Load-tracking
Date: Fri, 12 Oct 2012 10:20:36 +0530	[thread overview]
Message-ID: <20121012044618.18271.88332.stgit@preeti.in.ibm.com> (raw)

Hi everyone,

This patchset uses the per-entity-load-tracking patchset which will soon be
available in the kernel.It is based on the tip/master tree and the first 8
latest patches of sched:per-entity-load-tracking alone have been imported to
the tree to avoid the complexities of task groups and to hold back the
optimizations of this patch for now.

This patchset is an attempt to begin the integration of Per-entity-load-
metric for the cfs_rq,henceforth referred to as PJT's metric,with the load
balancer in a step wise fashion,and progress based on the consequences.

The following issues have been considered towards this:
[NOTE:an x% task referred to in the logs and below is calculated over a
duty cycle of 10ms.]

1.Consider a scenario,where there are two 10% tasks running on a cpu.The
  present code will consider the load on this queue to be 2048,while
  using PJT's metric the load is calculated to be <1000,rarely exceeding this
  limit.Although the tasks are not contributing much to the cpu load,they are
  decided to be moved by the scheduler.

  But one could argue that 'not moving one of these tasks could throttle
  them.If there was an idle cpu,perhaps we could have moved them'.While the
  power save mode would have been fine with not moving the task,the
  performance mode would prefer not to throttle the tasks.We could strive
  to strike a balance by making this decision tunable with certain parameters.
  This patchset includes such tunables.This issue is addressed in Patch[1/2].

2.We need to be able to do this cautiously,as the scheduler code is too
  complex.This patchset is an attempt to begin the integration of PJT's
  metric with the load balancer in a step wise fashion,and progress based on
  the consequences.
  I dont intend to vary the parameters used by the load balancer.Some
  parameters are however included anew to make decisions about including a
  sched group as a candidate for load balancing.

  This patchset therefore has two primary aims.
         Patch[1/2]: This patch aims at detecting short running tasks and
	 prevent their movement.In update_sg_lb_stats,dismiss a sched group
	 as a candidate for load balancing,if load calculated by PJT's metric
	 says that the average load on the sched_group <= 1024+(.15*1024).
	 This is a tunable,which can be varied after sufficient experiments.

         Patch[2/2]:In the current scheduler greater load would be analogous
         to more number of tasks.Therefore when the busiest group is picked
         from the sched domain in update_sd_lb_stats,only the loads of the
         groups are compared between them.If we were to use PJT's metric,a
         higher load does not necessarily mean more number of tasks.This
	 patch addresses this issue.

3.The next step towards integration should be in using the PJT's metric for
  comparison between the loads of the busy sched group and the sched
  group which has to pull the tasks,which happens in find_busiest_group.
---

Preeti U Murthy (2):
      sched:Prevent movement of short running tasks during load balancing
      sched:Pick the apt busy sched group during load balancing


 kernel/sched/fair.c |   38 +++++++++++++++++++++++++++++++++++---
 1 file changed, 35 insertions(+), 3 deletions(-)

--
Regards,
Preeti U Murthy


             reply	other threads:[~2012-10-12  4:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-12  4:50 Preeti U Murthy [this message]
2012-10-12  4:50 ` [RFC PATCH 1/2] sched:Prevent movement of short running tasks during load balancing Preeti U Murthy
2012-10-12  4:50 ` [RFC PATCH 2/2] sched:Pick the apt busy sched group " Preeti U Murthy
2012-10-12  5:16   ` preeti
2012-10-15  9:14 ` [RFC PATCH 0/2] sched: Load Balancing using Per-entity-Load-tracking preeti
2012-10-18 17:26 ` Morten Rasmussen
2012-10-19  4:17   ` preeti
2012-10-19  4:57     ` preeti

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=20121012044618.18271.88332.stgit@preeti.in.ibm.com \
    --to=preeti@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=svaidy@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®