From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Nick Piggin <piggin@cyberone.com.au>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Nick's scheduler policy v10
Date: Sun, 31 Aug 2003 13:20:58 -0700 [thread overview]
Message-ID: <1806700000.1062361257@[10.10.2.4]> (raw)
In-Reply-To: <3F5044DC.10305@cyberone.com.au>
> This is quite a big change from v8. Fixes a few bugs in child priority,
> and adds a small lower bound on the amount of history that is kept. This
> should improve "fork something" times hopefully, and stops new children
> being able to fluctuate priority so wildly.
>
> Eliminates "timeslice backboost" and only uses "priority backboost". This
> decreases scheduling latency quite nicely - I can only measure 130ms for
> a very low priority task, with a make -j3 and wildly moving an xterm around
> in front of a mozilla window.
>
> Makes a fairly fundamental change to how sleeping/running is accounted.
> It now takes into account time on the runqueue. This hopefully will keep
> priorities more stable under varying loads.
>
> Includes an upper bound on the amount of priority a task can get in one
> sleep. Hopefully this catches freak long sleeps like a SIGSTOP or unexpected
> swaps. This change breaks the priority calculation a little bit. I'm thinking
> about how to fix it.
>
> Feedback welcome! Its against 0-test4, as usual.
Oooh - much better.
Kernbench: (make -j vmlinux, maximal tasks)
Elapsed System User CPU
2.6.0-test4 45.87 116.92 571.10 1499.00
2.6.0-test4-nick 49.37 131.31 611.15 1500.75
2.6.0-test4-nick7a 49.48 125.95 617.71 1502.00
2.6.0-test4-nick10 46.91 114.03 584.16 1489.25
SDET 128 (see disclaimer)
Throughput Std. Dev
2.6.0-test4 100.0% 0.3%
2.6.0-test4-nick 102.9% 0.3%
2.6.0-test4-nick7a 105.1% 0.5%
2.6.0-test4-nick10 107.7% 0.2%
System time of kernbench is back to what it would be with virgin, or
actually a little less. Elapsed time is still up a little bit, along
with user time, but it's getting pretty close.
Have you looked at Rick Lindsley's schedstat patches? I don't have a
totally up-to-date version, but that might give us a better idea of
what's going on wrt migrations, balancing, etc.
I'll try to get together a broader set of benchmarks and hammer on this
some more ...
M.
next prev parent reply other threads:[~2003-08-31 20:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-30 6:31 [PATCH] Nick's scheduler policy v10 Nick Piggin
2003-08-31 20:20 ` Martin J. Bligh [this message]
2003-08-31 20:41 ` Martin J. Bligh
2003-09-01 1:47 ` Nick Piggin
2003-09-01 18:31 ` Martin J. Bligh
2003-09-02 8:04 ` Nick Piggin
2003-09-02 14:57 ` Martin J. Bligh
2003-09-02 23:50 ` Nick Piggin
2003-09-03 1:55 ` Con Kolivas
2003-09-01 1:44 ` Nick Piggin
2003-09-04 22:55 ` bill davidsen
2003-09-04 23:27 ` Mike Fedyk
2003-09-05 3:41 ` Bill Davidsen
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='1806700000.1062361257@[10.10.2.4]' \
--to=mbligh@aracnet.com \
--cc=linux-kernel@vger.kernel.org \
--cc=piggin@cyberone.com.au \
/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).