linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: namhyung@kernel.org (Namhyung Kim)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 3/6] sched: pack small tasks
Date: Fri, 21 Dec 2012 14:47:12 +0900	[thread overview]
Message-ID: <20121221054712.GA2933@danjae> (raw)
In-Reply-To: <CAKfTPtB9iz1ePsS+juQVRhuWREYB1duGWRJT7ya8XBXPhC-mkw@mail.gmail.com>

Hi Vincent,

On Thu, Dec 13, 2012 at 11:11:11AM +0100, Vincent Guittot wrote:
> On 13 December 2012 03:17, Alex Shi <alex.shi@intel.com> wrote:
> > On 12/12/2012 09:31 PM, Vincent Guittot wrote:
> >> +static bool is_buddy_busy(int cpu)
> >> +{
> >> +     struct rq *rq = cpu_rq(cpu);
> >> +
> >> +     /*
> >> +      * A busy buddy is a CPU with a high load or a small load with a lot of
> >> +      * running tasks.
> >> +      */
> >> +     return ((rq->avg.runnable_avg_sum << rq->nr_running) >
> >
> > If nr_running a bit big, rq->avg.runnable_avg_sum << rq->nr_running is
> > zero. you will get the wrong decision.
> 
> yes, I'm going to do that like below instead:
> return (rq->avg.runnable_avg_sum > (rq->avg.runnable_avg_period >>
> rq->nr_running));

Doesn't it consider nr_running too much?  It seems current is_buddy_busy
returns false on a cpu that has 1 task runs 40% cputime, but returns true
on a cpu that has 3 tasks runs 10% cputime each or for 2 tasks of 15%
cputime each, right?

I don't know what is correct, but just guessing that in a cpu's point
of view it'd be busier if it has a higher runnable_avg_sum than a
higher nr_running IMHO.


> 
> >
> >> +                     rq->avg.runnable_avg_period);
> >> +}
> >> +
> >> +static bool is_light_task(struct task_struct *p)
> >> +{
> >> +     /* A light task runs less than 25% in average */
> >> +     return ((p->se.avg.runnable_avg_sum << 1) <
> >> +                     p->se.avg.runnable_avg_period);
> >
> > 25% may not suitable for big machine.
> 
> Threshold is always an issue, which threshold should be suitable for
> big machine ?
> 
> I'm wondering if i should use the imbalance_pct value for computing
> the threshold

Anyway, I wonder how 'sum << 1' computes 25%.  Shouldn't it be << 2 ?

Thanks,
Namhyung

  parent reply	other threads:[~2012-12-21  5:47 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-12 13:31 [RFC PATCH v2 0/6] sched: packing small tasks Vincent Guittot
2012-12-12 13:31 ` RFC PATCH v2 1/6] Revert "sched: introduce temporary FAIR_GROUP_SCHED dependency for load-tracking" Vincent Guittot
2012-12-12 13:31 ` [PATCH 2/6] sched: add a new SD SHARE_POWERLINE flag for sched_domain Vincent Guittot
2012-12-13  2:24   ` Alex Shi
2012-12-13  8:53     ` Vincent Guittot
2012-12-12 13:31 ` [RFC PATCH v2 3/6] sched: pack small tasks Vincent Guittot
2012-12-13  2:17   ` Alex Shi
2012-12-13  2:43     ` Alex Shi
2012-12-13 10:11     ` Vincent Guittot
2012-12-13 14:25       ` Alex Shi
2012-12-13 14:53         ` Vincent Guittot
2012-12-13 15:48           ` Vincent Guittot
2012-12-14  1:46             ` Alex Shi
2012-12-14  9:33               ` Vincent Guittot
2012-12-16  7:12                 ` Alex Shi
2012-12-17  9:40                   ` Vincent Guittot
2012-12-17 15:24                     ` Alex Shi
2012-12-18  9:53                       ` Vincent Guittot
2012-12-18 11:29                         ` Alex Shi
2012-12-14  4:45         ` Mike Galbraith
2012-12-14  6:36           ` Alex Shi
2012-12-14  7:45             ` Mike Galbraith
2012-12-14  7:57               ` Alex Shi
2012-12-14 10:43               ` Vincent Guittot
2012-12-15  6:40                 ` Mike Galbraith
2012-12-17  3:13           ` Alex Shi
2012-12-21  5:47       ` Namhyung Kim [this message]
2012-12-21  8:53         ` Vincent Guittot
2012-12-21  8:59           ` Vincent Guittot
2012-12-12 13:31 ` [RFC PATCH v2 4/6] sched: secure access to other CPU statistics Vincent Guittot
2012-12-12 13:31 ` [RFC PATCH v2 5/6] sched: pack the idle load balance Vincent Guittot
2012-12-12 13:31 ` [RFC PATCH v2 6/6] ARM: sched: clear SD_SHARE_POWERLINE Vincent Guittot

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=20121221054712.GA2933@danjae \
    --to=namhyung@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).