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
Date: Mon, 14 Jul 2003 17:40:04 +0200
Message-Id: <WRGA0805JD97A7A6YTZT94KB0B0JI65.3f12ced4@monpc>
Subject: Re: [RFC][PATCH] SCHED_ISO for interactivity
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-15"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3087
Lines: 71

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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/