From: Con Kolivas <kernel@kolivas.org>
To: Felipe Alfaro Solana <felipe_alfaro@linuxmail.org>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
linux kernel mailing list <linux-kernel@vger.kernel.org>,
Willy Tarreau <willy@w.ods.org>
Subject: Re: [PATCH] Staircase scheduler v7.4
Date: Mon, 28 Jun 2004 22:11:22 +1000 [thread overview]
Message-ID: <40E00AEA.4050709@kolivas.org> (raw)
In-Reply-To: <1088423626.1699.0.camel@teapot.felipe-alfaro.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Felipe Alfaro Solana wrote:
| On Mon, 2004-06-28 at 18:49 +1000, Nick Piggin wrote:
|
|>Felipe Alfaro Solana wrote:
|>
|>
|>>I have tested 2.6.7-bk10 plus from_2.6.7_to_staircase_7.7 patch and,
|>>while it's definitively better than previous versions, it still feels a
|>>little jerky when moving windows in X11 wrt to -mm3. Renicing makes it a
|>>little bit smoother, but not as much as -mm3 without renicing.
|>>
|>
|>You know, if renicing X makes it smoother, then that is a good thing
|>IMO. X needs large amounts of CPU and low latency in order to get
|>good interactivity, which is something the scheduler shouldn't give
|>to a process unless it is told to.
|
|
| But the problem here is that -ck3 with X reniced to -10 is not as smooth
| as -mm3 with no renicing. That's what worries me.
The design of staircase would make renicing normal interactive things
- -ve values bad for the latency of other nice 0 tasks s is not
recommended for X or games etc. Initial scheduling latency is very
dependent on nice value in staircase. If you set a cpu hog to nice -5 it
will hurt audio at nice 0 and so on. Nicing latency unimportant things
with +ve values is more useful with this design. If you run X and
evolution at the same nice value they will get equal cpu share for
example so moving windows means redrawing evolution and X moving get
equal cpu. Nicing evolution +ve will make X smoother compared to
evolution redrawing and so on...
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA4ArqZUg7+tp6mRURAn2BAJ4hkK871JXO/R3AvwR0CzKoLg6f6wCeNBP/
Y1aOfCWLR5QtVZvq8wdpToI=
=xit3
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2004-06-28 12:11 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-25 16:40 [PATCH] Staircase scheduler v7.4 Michael Buesch
2004-06-25 16:46 ` Con Kolivas
2004-06-25 18:44 ` Michael Buesch
2004-06-25 19:05 ` Willy Tarreau
2004-06-25 19:48 ` Michael Buesch
2004-06-26 1:11 ` kernel
2004-06-26 16:33 ` Michael Buesch
2004-06-26 17:29 ` Michael Buesch
2004-06-27 9:14 ` Con Kolivas
2004-06-27 19:17 ` Felipe Alfaro Solana
2004-06-27 19:28 ` Michael Buesch
2004-06-27 21:55 ` Felipe Alfaro Solana
2004-06-28 0:15 ` Con Kolivas
2004-06-28 8:40 ` Felipe Alfaro Solana
2004-06-28 8:49 ` Nick Piggin
2004-06-28 11:53 ` Felipe Alfaro Solana
2004-06-28 12:11 ` Con Kolivas [this message]
2004-06-28 15:03 ` Oswald Buddenhagen
2004-06-28 15:19 ` Con Kolivas
2004-06-28 15:39 ` Oswald Buddenhagen
2004-06-28 17:11 ` Felipe Alfaro Solana
2004-06-29 4:36 ` Nick Piggin
2004-06-28 23:21 ` Peter Williams
2004-06-29 4:44 ` Nick Piggin
2004-06-29 6:01 ` Ed Sweetman
2004-06-29 6:55 ` Nick Piggin
2004-06-26 2:05 ` Con Kolivas
2004-06-27 10:24 ` Con Kolivas
2004-06-27 10:27 ` Con Kolivas
2004-06-27 23:50 ` Peter Williams
2004-06-27 12:00 ` Con Kolivas
2004-06-27 12:04 ` Con Kolivas
2004-06-27 12:54 ` Michael Buesch
2004-06-27 13:15 ` Con Kolivas
2004-06-25 16:46 ` Michael Buesch
-- strict thread matches above, loose matches on Subject: below --
2004-06-25 14:38 Con Kolivas
2004-06-25 18:32 ` Matthias Urlichs
2004-06-26 1:28 ` Con Kolivas
2004-06-25 22:20 ` Willy Tarreau
2004-06-26 1:05 ` kernel
2004-06-26 20:04 ` Wes Janzen
2004-06-26 20:11 ` Michael Buesch
2004-06-26 21:14 ` Wes Janzen
2004-06-26 21:38 ` Prakash K. Cheemplavam
2004-06-27 9:16 ` Con Kolivas
2004-06-27 11:40 ` Grzegorz Kulewski
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=40E00AEA.4050709@kolivas.org \
--to=kernel@kolivas.org \
--cc=felipe_alfaro@linuxmail.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=willy@w.ods.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox