From: Yaroslav Rastrigin <yarick@relex.ru>
To: Nick Piggin <piggin@cyberone.com.au>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Nick's scheduler policy v7
Date: Tue, 26 Aug 2003 13:44:05 +0400 [thread overview]
Message-ID: <200308261344.05642.yarick@relex.ru> (raw)
In-Reply-To: <3F49E7D1.4000309@cyberone.com.au>
Hi !
>
> This one has a few changes. Children now get a priority boost
> on fork, and parents retain more priority after forking a child,
> however exiting CPU hogs will now penalise parents a bit.
>
> Timeslice scaling was tweaked a bit. Oh and remember raising X's
> priority should _help_ interactivity with this patch, and IMO is
> not an unreasonable thing to be doing.
>
> Please test. I'm not getting enough feedback!
And here's my report (almost no numbers, everything is purely subjective).
I haven't tested Con's O18.1 yet, so my comparision is against -test4 vanilla.
First (and most subjective opinion) - great. Under casual load (Opera
rendering page and using its motifwrapper to handle flash (it's a CPU hog
alone) + ocassional compilation + XMMS using ALSA ) everything feels very
smooth _and_ responsive, no XMMS jerks, windows are moving nicely - X is
definitely not starved, ps ax in xterm displays its output almost instantly,
apps startup time is also very pleasantly low - all in all great.
Unusual load (make -j 4 bzImage + aforementioned activity ) - I was able to
notice 1 jerk in XMMS (wasn't able to reproduce, so this is acceptable),
application startup time is slightly worse, but nonetheless useable and once
started, all apps are quite smooth, but X is definitely starved, and it has
great impact on WM - window movement is jerky and feels bad. However, renice
-20 <X pid> cures this behavior completely, without any noticeable penalty on
another apps - music is playing nicely, page rendering is still clean and
nice.
Overall - very nice.
I'll stick to your scheduling policy for a while .
System specs:
IBM ThinkPad T21, PIII-800Mhz , 256Mb.
Linux 2.6.0-test4, APM, ALSA, anticipatory IO scheduling
XFree 4.3.99.9
P.S. make clean && make -j 4 bzImage completed while I was writing this
letter, so I'm assuming throughput is also OK for me.
--
With all the best, yarick at relex dot ru.
next prev parent reply other threads:[~2003-08-26 9:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-24 12:35 [PATCH] Nick's scheduler policy Nick Piggin
2003-08-24 14:29 ` Felipe Alfaro Solana
2003-08-25 3:05 ` Nick Piggin
2003-08-25 22:30 ` Bill Davidsen
2003-08-24 16:55 ` Martin J. Bligh
2003-08-25 3:00 ` Nick Piggin
2003-08-25 10:41 ` [PATCH] Nick's scheduler policy v7 Nick Piggin
2003-08-25 11:03 ` Felipe Alfaro Solana
2003-08-25 14:36 ` Måns Rullgård
2003-08-26 3:24 ` Martin J. Bligh
2003-08-26 4:04 ` Nick Piggin
2003-08-26 9:44 ` Yaroslav Rastrigin [this message]
2003-08-27 9:28 ` Mike Galbraith
2003-08-25 3:27 ` [PATCH] Nick's scheduler policy Randy.Dunlap
2003-08-25 3:36 ` Nick Piggin
2003-08-26 3:16 ` Mike Fedyk
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=200308261344.05642.yarick@relex.ru \
--to=yarick@relex.ru \
--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
all inboxes | Powered by JetHome®