From: Guillaume Chazarain <gfc@altern.org>
To: Con Kolivas <kernel@kolivas.org>
Cc: linux-kernel@vger.kernel.org, phillips@arcor.de, smiler@lanil.mine.nu
Subject: Re: [RFC][PATCH] SCHED_ISO for interactivity
Date: Mon, 14 Jul 2003 17:40:04 +0200 [thread overview]
Message-ID: <WRGA0805JD97A7A6YTZT94KB0B0JI65.3f12ced4@monpc> (raw)
14/07/03 02:07:34, Con Kolivas <kernel@kolivas.org> wrote:
>On Mon, 14 Jul 2003 00:54, Guillaume Chazarain wrote:
>> Good, with ISO_PENALTY == 2, I can smoothly move big windows (with
>> ISO_PENALTY == 5 it was smooth only with very small windows), but it lets
>> me move them smoothly during less time than stock :(
>
>Less time than stock? I don't understand you. You can only move them smoothly
>for a small time or they move faster or... ?
With the previous SCHED_ISO, moving big windows was smooth for a short time,
but then it became jerky. Unlike with stock where it was smooth all the time.
>Indeed it is artificial, and probably never a real world condition unless it
>was specifically an attack, but it would never bring the system to a halt,
>just some minor audio hiccups while it adjusted.
This is also true for stock.
>> >The logical conclusion of this idea where there is a dynamic policy
>> > assigned to interactive tasks is a dynamic policy assigned to non
>> > interactive tasks that get treated in the opposite way. I'll code
>> > something for that soon, now that I've had more feedback on the first
>> > part.
>>
>> Interesting, let's see :)
>> But as the interactive bonus can already be negative I wonder what use
>> will have another variable.
>
>As it is, the penalty will be no different to what it currently gets to (in
>the same way sched_iso get the same bonus they normally would). The
>difference is once they are moved to the different policy it is much harder
>for them to change from that state, always getting the maximum penalty, and
>being expired each time they run out of timeslice instead of getting a chance
>to be put onto the active array. Neither of these new states is very
>different to what normal policy tasks get except for the fact they dont
>change interactive state without a lot more effort.
OK, the latest SCHED_ISO fixed my problem, but now I am afraid of the scheduler
trying to be too intelligent, because if it makes the wrong choice the bad result
will be much more noticeable.
I like the simplicity of stock, the interactivity bonus is given in a simple and
understandable way, and if it's not given to the process you want, you can always
renice it or make it RT.
I have to admit that
p->sleep_avg = MIN_SLEEP_AVG * (MAX_BONUS - INTERACTIVE_DELTA - 1) / MAX_BONUS;
and
if ((runtime - MIN_SLEEP_AVG < MAX_SLEEP_AVG) && (runtime * JUST_INTERACTIVE > p->sleep_avg))
p->sleep_avg += (runtime * JUST_INTERACTIVE - p->sleep_avg) *
(MAX_SLEEP_AVG + MIN_SLEEP_AVG - runtime) / MAX_SLEEP_AVG;
are quite obscure to me.
Also, I don't understand your MAX_BONUS definition:
((MAX_USER_PRIO - MAX_RT_PRIO) * PRIO_BONUS_RATIO / 100) it evaluates to -15
I would use ((MAX_PRIO - MAX_RT_PRIO) * PRIO_BONUS_RATIO / 100 / 2) since it gives 5.
Guillaume
next reply other threads:[~2003-07-14 15:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-14 15:40 Guillaume Chazarain [this message]
2003-07-14 21:45 ` [RFC][PATCH] SCHED_ISO for interactivity Con Kolivas
-- strict thread matches above, loose matches on Subject: below --
2003-07-13 14:54 Guillaume Chazarain
2003-07-14 0:07 ` Con Kolivas
2003-07-14 4:05 ` Con Kolivas
[not found] <JEPOQNA0LFV95MFCPMSKONGFSNX.3f113751@monpc>
2003-07-13 12:53 ` Con Kolivas
2003-07-13 10:41 Guillaume Chazarain
2003-07-13 11:54 ` Christian Axelsson
2003-07-13 14:06 ` Con Kolivas
2003-07-11 10:53 Con Kolivas
[not found] ` <1068.::ffff:217.208.49.177.1057927722.squirrel@lanil.mine.nu>
2003-07-11 14:30 ` Con Kolivas
2003-07-11 23:37 ` Christian Axelsson
2003-07-12 0:13 ` Con Kolivas
2003-07-12 15:39 ` Con Kolivas
2003-07-12 16:27 ` Michael Buesch
2003-07-12 16:28 ` Christian Axelsson
2003-07-13 2:26 ` Con Kolivas
2003-07-13 3:40 ` Christian Axelsson
2003-07-13 20:07 ` Daniel Phillips
2003-07-12 15:49 ` William Lee Irwin III
2003-07-12 15:53 ` Con Kolivas
2003-07-13 20:03 ` Daniel Phillips
2003-07-14 0:13 ` Con Kolivas
2003-07-14 2:40 ` Daniel Phillips
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=WRGA0805JD97A7A6YTZT94KB0B0JI65.3f12ced4@monpc \
--to=gfc@altern.org \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=phillips@arcor.de \
--cc=smiler@lanil.mine.nu \
/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).