From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Al Boldi <a1426z@gawab.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] 2.6.21-rc4 nicksched v32
Date: Fri, 23 Mar 2007 13:33:41 +1100 [thread overview]
Message-ID: <46033C85.2010008@yahoo.com.au> (raw)
In-Reply-To: <200703221740.47801.a1426z@gawab.com>
Al Boldi wrote:
> Nick Piggin wrote:
>>Timeslices get scaled by /proc/sys/kernel/base_timeslice. If you have bad
>>interactivity you could try lowering this and see if it helps.
>
>
> As I am on 2.6.20, I can't really test this patch, but I tried your sched
> from PlugSched and its not bad.
OK, the one in plugsched is reasonably different...
> I'm getting strange numbers with chew.c, though. Try this:
> Boot into /bin/sh
> Run ./chew on one console.
> Run ./chew on another console.
> Watch latencies.
>
> Console 1:
> pid 671, prio 0, out for 799 ms, ran for 800 ms, load 50%
> pid 671, prio 0, out for 799 ms, ran for 801 ms, load 50%
> pid 671, prio 0, out for 799 ms, ran for 799 ms, load 49%
> pid 671, prio 0, out for 800 ms, ran for 800 ms, load 49%
>
> Console 2:
> pid 672, prio 0, out for 800 ms, ran for 799 ms, load 49%
> pid 672, prio 0, out for 799 ms, ran for 800 ms, load 50%
> pid 672, prio 0, out for 799 ms, ran for 800 ms, load 50%
> pid 672, prio 0, out for 799 ms, ran for 799 ms, load 49%
> pid 672, prio 0, out for 799 ms, ran for 799 ms, load 49%
>
> Looks good, but now add a cpu-hog, ie. while :; do :; done
>
> Console 1:
>
> pid 671, prio 0, out for 799 ms, ran for 399 ms, load 33%
> pid 671, prio 0, out for 799 ms, ran for 399 ms, load 33%
> pid 671, prio 0, out for 799 ms, ran for 399 ms, load 33%
> pid 671, prio 0, out for 799 ms, ran for 399 ms, load 33%
>
> Console 2:
> pid 672, prio 0, out for 1599 ms, ran for 799 ms, load 33%
> pid 672, prio 0, out for 1599 ms, ran for 799 ms, load 33%
> pid 672, prio 0, out for 1599 ms, ran for 800 ms, load 33%
> pid 672, prio 0, out for 1599 ms, ran for 799 ms, load 33%
>
> It's smooth, but latencies are double on console2. Easy enough to fix,
> though, just press scrollock to induce a sleep and then release.
Yeah, this issue is since fixed in v32.
> Also, latencies are huge. Is there a way to fix latencies per nice?
Latencies should be quite a bit lower in v32. You can lower it
with /proc/sys/kernel/base_timeslice, however I would like to see
whether the current setting gives reasonable interactivity.
Thanks,
Nick
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2007-03-23 2:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-22 14:40 [patch] 2.6.21-rc4 nicksched v32 Al Boldi
2007-03-23 2:33 ` Nick Piggin [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-03-22 10:10 Nick Piggin
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=46033C85.2010008@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=a1426z@gawab.com \
--cc=linux-kernel@vger.kernel.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.