All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Mike Galbraith <efault@gmx.de>
Cc: Steven Cole <elenstev@mesatop.com>,
	Ed Tomlinson <tomlins@cam.org>, Andrew Morton <akpm@digeo.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>
Subject: Re: 2.5.65-mm2
Date: Fri, 21 Mar 2003 07:06:55 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.44.0303210659530.2406-100000@localhost.localdomain> (raw)
In-Reply-To: <5.2.0.9.2.20030320194530.01985440@pop.gmx.net>


On Thu, 20 Mar 2003, Mike Galbraith wrote:

> This is a side effect of Ingo's (nice!) latency change methinks.  When
> you have several cpu hogs running (dbench), and they are cleaning your
> cpu's clock by using their full bandwidth to attain maximum throughput,
> and they then break up their timeslice in order to provide you with more
> responsiveness, and then their _cumulative_ sleep time between (round
> robin!) cpu hard burns is added to their sleep_avg, [...]

actually, the round-robining for finer-grained timeslices should not
impact the sleep average at all, because the roundrobin is done while the
task is still _running_, ie. the sleep average does not get impacted.
Otherwise we'd have elevated priority of simple CPU-intensive
applications, which would be Bad.

The way the sleep-average is maintained is balanced very carefully in the
O(1) scheduler. There are three states a task can be in:

 - sleeping: the sleep average increases
 - running but not executing: the sleep average stagnates
 - executing on a CPU: the sleep average decreases

ie. in the roundrobin case the tasks will neither increase, nor decrease
their sleep average - they are in essence 'frozen'. The moment they get
scheduled on a CPU for execution, their sleep average starts to decrease
again. (and once they go to sleep, their sleep average increases.)

so whatever effect you are seeing, it must be something else.

	Ingo


WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@elte.hu>
To: Mike Galbraith <efault@gmx.de>
Cc: Steven Cole <elenstev@mesatop.com>,
	Ed Tomlinson <tomlins@cam.org>, Andrew Morton <akpm@digeo.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org
Subject: Re: 2.5.65-mm2
Date: Fri, 21 Mar 2003 07:06:55 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.44.0303210659530.2406-100000@localhost.localdomain> (raw)
In-Reply-To: <5.2.0.9.2.20030320194530.01985440@pop.gmx.net>

On Thu, 20 Mar 2003, Mike Galbraith wrote:

> This is a side effect of Ingo's (nice!) latency change methinks.  When
> you have several cpu hogs running (dbench), and they are cleaning your
> cpu's clock by using their full bandwidth to attain maximum throughput,
> and they then break up their timeslice in order to provide you with more
> responsiveness, and then their _cumulative_ sleep time between (round
> robin!) cpu hard burns is added to their sleep_avg, [...]

actually, the round-robining for finer-grained timeslices should not
impact the sleep average at all, because the roundrobin is done while the
task is still _running_, ie. the sleep average does not get impacted.
Otherwise we'd have elevated priority of simple CPU-intensive
applications, which would be Bad.

The way the sleep-average is maintained is balanced very carefully in the
O(1) scheduler. There are three states a task can be in:

 - sleeping: the sleep average increases
 - running but not executing: the sleep average stagnates
 - executing on a CPU: the sleep average decreases

ie. in the roundrobin case the tasks will neither increase, nor decrease
their sleep average - they are in essence 'frozen'. The moment they get
scheduled on a CPU for execution, their sleep average starts to decrease
again. (and once they go to sleep, their sleep average increases.)

so whatever effect you are seeing, it must be something else.

	Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

  parent reply	other threads:[~2003-03-21  5:56 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-19  9:21 2.5.65-mm2 Andrew Morton
2003-03-19  9:21 ` 2.5.65-mm2 Andrew Morton
2003-03-19 10:07 ` 2.5.65-mm2 Alexander Hoogerhuis
2003-03-19 10:16 ` 2.5.65-mm2 Alexander Hoogerhuis
2003-03-19 10:16   ` 2.5.65-mm2 Alexander Hoogerhuis
2003-03-19 10:26 ` 2.5.65-mm2 Danny ter Haar
2003-03-19 19:51 ` 2.5.65-mm2 Steven Cole
2003-03-19 19:51   ` 2.5.65-mm2 Steven Cole
2003-03-19 20:10   ` 2.5.65-mm2 Andrew Morton
2003-03-19 20:10     ` 2.5.65-mm2 Andrew Morton
2003-03-19 20:57     ` 2.5.65-mm2 Steven P. Cole
2003-03-19 20:57       ` 2.5.65-mm2 Steven P. Cole
2003-03-19 22:02       ` 2.5.65-mm2 Steven P. Cole
2003-03-19 22:02         ` 2.5.65-mm2 Steven P. Cole
2003-03-19 22:17         ` 2.5.65-mm2 jjs
2003-03-19 22:51           ` 2.5.65-mm2 Steven P. Cole
2003-03-19 23:04             ` 2.5.65-mm2 Robert Love
2003-03-19 23:19               ` 2.5.65-mm2 Steven P. Cole
2003-03-20  4:50               ` 2.5.65-mm2 Mike Galbraith
2003-03-19 23:09             ` 2.5.65-mm2 jjs
2003-03-20  0:33         ` 2.5.65-mm2 Andrew Morton
2003-03-20  0:33           ` 2.5.65-mm2 Andrew Morton
2003-03-19 23:45           ` 2.5.65-mm2 Steven P. Cole
2003-03-19 23:45             ` 2.5.65-mm2 Steven P. Cole
2003-03-20  4:27             ` 2.5.65-mm2 Ed Tomlinson
2003-03-20  5:04               ` 2.5.65-mm2 Steven Cole
2003-03-20  5:04                 ` 2.5.65-mm2 Steven Cole
2003-03-20 14:36               ` 2.5.65-mm2 Steven Cole
2003-03-20 14:36                 ` 2.5.65-mm2 Steven Cole
2003-03-20 19:48                 ` 2.5.65-mm2 Mike Galbraith
2003-03-20 19:48                   ` 2.5.65-mm2 Mike Galbraith
2003-03-20 20:12                   ` 2.5.65-mm2 Steven P. Cole
2003-03-20 20:12                     ` 2.5.65-mm2 Steven P. Cole
2003-03-20 21:07                     ` 2.5.65-mm2 Mike Galbraith
2003-03-20 21:15                       ` 2.5.65-mm2 Steven P. Cole
2003-03-20 21:15                         ` 2.5.65-mm2 Steven P. Cole
2003-03-21  5:20                         ` 2.5.65-mm2 Mike Galbraith
2003-03-21  6:06                   ` Ingo Molnar [this message]
2003-03-21  6:06                     ` 2.5.65-mm2 Ingo Molnar
2003-03-21  6:16                   ` 2.5.65-mm2 Ingo Molnar
2003-03-21  6:16                     ` 2.5.65-mm2 Ingo Molnar
     [not found]                   ` <Pine.LNX.4.44.0303210710490.2533-100000@localhost.localdom ain>
2003-03-22 19:50                     ` 2.5.65-mm2 Mike Galbraith
2003-03-22 19:50                       ` 2.5.65-mm2 Mike Galbraith
2003-03-19 23:17 2.5.65-mm2 Charles Baylis
2003-03-20  1:38 ` 2.5.65-mm2 Andrew Morton
2003-03-20  4:56 ` 2.5.65-mm2 Mike Galbraith

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=Pine.LNX.4.44.0303210659530.2406-100000@localhost.localdomain \
    --to=mingo@elte.hu \
    --cc=akpm@digeo.com \
    --cc=efault@gmx.de \
    --cc=elenstev@mesatop.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tomlins@cam.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 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.