public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mike Galbraith <efault@gmx.de>,
	Arjan van de Ven <arjan@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Balbir Singh <balbir@linux.vnet.ibm.com>,
	Dmitry Adamushko <dmitry.adamushko@gmail.com>
Subject: Re: [patch] CFS scheduler, -v15
Date: Wed, 6 Jun 2007 09:01:43 +0200	[thread overview]
Message-ID: <20070606070143.GA7375@elte.hu> (raw)
In-Reply-To: <20070606064228.GA22443@in.ibm.com>


* Srivatsa Vaddagiri <vatsa@in.ibm.com> wrote:

> > i'm pleased to announce release -v15 of the CFS scheduler patchset.
> 
> Do I smell a bug when a task switches its scheduling classes?
> 
> Lets say a task was in real-time class for a long time and switches to 
> fair-sched class. When update_curr() is called on this new fair-sched 
> task, some of required fields (for ex: exec_start) are uninitialized 
> and can lead to bogus calculations?

yep, you are right. Dmitry Adamushko and Balbir Singh are working on 
this area, and my tree already contains the fixes for rt task's 
exec_start. (this also gives us the ability to have precise 'top' 
statistics for RT tasks.) So this should be fixed in -v16. (Since it's 
quite uncommon for a task to drop in and out of scheduling classes, this 
problem was found via review, not via any user-visible regression.)

> Also, real-time tasks are currently influencing fair clock 
> calculations (because there is only one raw_weighted_load field per 
> runqueue). Is that intentional?

yep - the 'fair clock' in essence freezes when RT tasks are running (but 
not completely). Can you think of any bad effect from this perhaps? It's 
useful to have unified load-balancing (smpnice-driven) between the RT 
and fair classes.

	Ingo

  reply	other threads:[~2007-06-06  7:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-31 15:09 [patch] CFS scheduler, -v15 Ingo Molnar
2007-06-06  6:42 ` Srivatsa Vaddagiri
2007-06-06  7:01   ` Ingo Molnar [this message]
2007-06-06  7:43     ` Srivatsa Vaddagiri
2007-06-06  9:08       ` Dmitry Adamushko
2007-06-06 10:37         ` Balbir Singh
2007-06-06 10:59           ` Srivatsa Vaddagiri
2007-06-06 11:19             ` Dmitry Adamushko
2007-06-06 11:37               ` Srivatsa Vaddagiri
2007-06-06 11:46                 ` Srivatsa Vaddagiri
2007-06-14 12:43                 ` Srivatsa Vaddagiri

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=20070606070143.GA7375@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=dmitry.adamushko@gmail.com \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=vatsa@in.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