mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Chase Douglas <chase.douglas@canonical.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <peterz@infradead.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	kernel-team <kernel-team@lists.ubuntu.com>
Subject: Re: [REGRESSION 2.6.30][PATCH 1/1] sched: defer idle accounting till after load update period
Date: Thu, 1 Apr 2010 22:18:36 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.00.1004012203270.32352@localhost.localdomain> (raw)
In-Reply-To: <h2s40ec3ea41004011300zaa5699f0kcf07434fec9b1aab@mail.gmail.com>

On Thu, 1 Apr 2010, Chase Douglas wrote:
> On Thu, Apr 1, 2010 at 3:37 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > Yes, we can do something smarter. First thing is to fix the
> > nr_uninterruptible accounting which can become negative. Peter looked
> > into that already and we really need to fix this first before doing
> > anything smart about that load avg stuff.
> 
> I noticed this too, and figured it was some clever accounting :). If
> this is a real bug, I'd be happy to take a look at it as well.
> 
> What do you have in mind as a smarter way of fixing this issue, and
> why is it dependent on fixing the absolute values of each runqueue's
> nr_uninterruptible count?

Well, the uninterruptible count imbalance is preventing us to calc the
load avg per cpu, which is something the power saving folks are
interested in.

If that is fixed we probably have a good chance to collect the per cpu
stuff and build a combined one - have not looked into the gory details
of the math yet.

Also we need to think about a more clever way than just accounting the
number of running and uninterruptible tasks. What we really want is to
use the numbers which the scheduler has handy, i.e how many tasks did
we run since we did the last loadavg calculation. It was always
possible (even before the big loadavg changes) to create a task which
consumes 50% of a CPU and never shows up in the loadavg calculations
at all.

Thanks,

	tglx

  reply	other threads:[~2010-04-01 20:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-29 13:41 [REGRESSION 2.6.30][PATCH 0/1] " Chase Douglas
2010-03-29 13:41 ` [REGRESSION 2.6.30][PATCH 1/1] " Chase Douglas
2010-03-29 14:41   ` Peter Zijlstra
2010-03-29 17:20     ` Chase Douglas
2010-04-01 19:27   ` Andrew Morton
2010-04-01 19:37     ` Thomas Gleixner
2010-04-01 20:00       ` Chase Douglas
2010-04-01 20:18         ` Thomas Gleixner [this message]
2010-04-01 20:32           ` Chase Douglas
2010-04-01 20:37             ` Thomas Gleixner
2010-04-02  7:59           ` Peter Zijlstra
2010-04-05 14:44             ` Chase Douglas
2010-04-01 19:56     ` Chase Douglas
2010-04-01 20:01       ` Thomas Gleixner
2010-04-13 20:39         ` Andrew Morton
2010-04-13 21:02           ` Thomas Gleixner
2010-04-13 21:06             ` Chase Douglas

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=alpine.LFD.2.00.1004012203270.32352@localhost.localdomain \
    --to=tglx@linutronix.de \
    --cc=akpm@linux-foundation.org \
    --cc=chase.douglas@canonical.com \
    --cc=kernel-team@lists.ubuntu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=rjw@sisk.pl \
    /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®