From: Mika Liljeberg <Mika.Liljeberg@welho.com>
To: george anzinger <george@mvista.com>
Cc: Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Benjamin LaHaise <bcrl@redhat.com>,
Linus Torvalds <torvalds@transmeta.com>,
linux-kernel@vger.kernel.org,
Davide Libenzi <davidel@xmailserver.org>
Subject: Re: Context switch times
Date: Mon, 08 Oct 2001 01:06:01 +0300 [thread overview]
Message-ID: <3BC0D1C9.63C7F218@welho.com> (raw)
In-Reply-To: <E15pWfR-0006g5-00@the-village.bc.nu> <3BC02709.A8E6F999@welho.com> <20011007150358.G30515@nightmaster.csn.tu-chemnitz.de> <3BC05D2E.94F05935@welho.com> <20011007162439.P748@nightmaster.csn.tu-chemnitz.de> <3BC067BB.73AF1EB5@welho.com> <3BC0982A.84ECBE7B@mvista.com>
george anzinger wrote:
> On the face of it this only seems unfair. I think what we want to do is
> to allocate the cpu resources among competing tasks as dictated by their
> NICE values. If each task gets its allotted share it should not matter
> if one of them is monopolizing one cpu. This is not to say that things
> will work out this way, but to say that this is not the measure, nor the
> thing to look at.
I'm not sure I fully understood what you're driving at, but surely "each
task getting its allotted share" implies that the tasks are correctly
balanced across CPUs? I take your point that if you're only interested
in the total completion time of certain set of tasks, it doesn't matter
how they are divided among CPUs as long as each CPU is crunching at
maximum capacity. However, if you're interested in the completion time
of a particular task (or if the task is mostly CPU bound but with
occasional interaction with the user), you need to provide fairness all
the way through the scheduling process. This, IMHO, implies balancing
the tasks across CPUs.
How the balance is determined is another issue, though. I basically
proposed summing the time slices consumed by tasks executing on a single
CPU and using that as the comparison value. Davide Libenzi, on the other
hand, simply proposed using the number of tasks.
I would contend that if you can evenly divide a particular load across
multiple CPUs, you can then run a pre-emptive scheduler on each CPUs run
queue independently, without regard for the other CPUs, and still come
out with high CPU utilization and reasonable completion times for all
tasks. This has the major advantage of limiting spinlock contention to
the load balancer, instead of risking it at every schedule().
> I suggest that, using the "recalculate tick" as a measure of time (I
> know it is not very linear)
I'll take your word for it as I'm not very familiar with the current
scheduler. The main thing is to do the rebalancing periodically and to
have a reliable way of estimating the loading (not utilization) of each
CPU.
> when a cpu finds itself with nothing to do
> (because all its tasks have completed their slices or blocked) and other
> cpus have tasks in their queues it is time to "shop" for a new task to
> run.
This again has the problem that you only look for new tasks if you have
nothing to do. While this would work if you only look at the total
completion time of a set of tasks, it does nothing to ensure fair
scheduling for a particular task.
> This would then do load balancing just before each "recalculate
> tick".
> Of course, the above assumes that each cpu has its own run queue.
>
> George
Regards,
MikaL
next prev parent reply other threads:[~2001-10-07 22:06 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-04 21:04 Context switch times Mike Kravetz
2001-10-04 21:14 ` arjan
2001-10-04 21:25 ` David S. Miller
2001-10-04 21:39 ` Richard Gooch
2001-10-04 21:52 ` David S. Miller
2001-10-04 21:55 ` Benjamin LaHaise
2001-10-04 22:35 ` Davide Libenzi
2001-10-04 22:49 ` Mike Kravetz
2001-10-04 22:42 ` Linus Torvalds
2001-10-04 22:53 ` Benjamin LaHaise
2001-10-05 15:13 ` Alan Cox
2001-10-05 17:49 ` george anzinger
2001-10-05 22:29 ` Alan Cox
2001-10-05 22:56 ` Davide Libenzi
2001-10-05 23:04 ` Alan Cox
2001-10-05 23:16 ` Davide Libenzi
2001-10-05 23:17 ` Alan Cox
2001-10-05 23:21 ` Davide Libenzi
2001-10-05 23:43 ` Roger Larsson
2001-10-07 1:20 ` george anzinger
2001-10-07 1:33 ` Bill Davidsen
2001-10-07 9:56 ` Alan Cox
2001-10-06 2:24 ` Albert D. Cahalan
2001-10-06 2:57 ` Davide Libenzi
2001-10-07 9:57 ` Mika Liljeberg
2001-10-07 13:03 ` Ingo Oeser
2001-10-07 13:48 ` Mika Liljeberg
2001-10-07 14:24 ` Ingo Oeser
2001-10-07 14:33 ` Mika Liljeberg
2001-10-07 18:00 ` george anzinger
2001-10-07 22:06 ` Mika Liljeberg [this message]
2001-10-07 22:31 ` Davide Libenzi
2001-10-07 22:33 ` Mika Liljeberg
2001-10-07 23:49 ` george anzinger
2001-10-08 21:07 ` Mika Liljeberg
2001-10-08 22:54 ` discontig physical memory Petko Manolov
2001-10-08 23:05 ` David S. Miller
2001-10-08 23:18 ` Petko Manolov
2001-10-08 23:29 ` David S. Miller
2001-10-09 0:34 ` Petko Manolov
2001-10-09 0:36 ` Petko Manolov
2001-10-09 1:37 ` David S. Miller
2001-10-09 2:43 ` Petko Manolov
2001-10-08 15:19 ` Context switch times bill davidsen
2001-10-10 6:07 ` Mike Fedyk
2001-10-07 18:39 ` Davide Libenzi
2001-10-09 20:37 ` Hubertus Franke
2001-10-09 23:50 ` george anzinger
2001-10-11 10:52 ` Hubertus Franke
2001-10-04 23:41 ` Mike Kravetz
2001-10-04 23:50 ` Linus Torvalds
2001-10-05 15:15 ` Eric W. Biederman
2001-10-04 23:56 ` Davide Libenzi
2001-10-05 0:45 ` Andrea Arcangeli
2001-10-05 4:35 ` Mike Kravetz
2001-10-07 17:59 ` Andrea Arcangeli
2001-10-07 19:54 ` george anzinger
2001-10-07 20:24 ` Andrea Arcangeli
2001-10-09 4:55 ` Richard Gooch
2001-10-09 5:00 ` David S. Miller
2001-10-09 13:49 ` bill davidsen
-- strict thread matches above, loose matches on Subject: below --
2001-10-05 6:31 Michailidis, Dimitrios
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=3BC0D1C9.63C7F218@welho.com \
--to=mika.liljeberg@welho.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bcrl@redhat.com \
--cc=davidel@xmailserver.org \
--cc=george@mvista.com \
--cc=ingo.oeser@informatik.tu-chemnitz.de \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.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