From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S270664AbTGNPXc (ORCPT ); Mon, 14 Jul 2003 11:23:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S270663AbTGNPXc (ORCPT ); Mon, 14 Jul 2003 11:23:32 -0400 Received: from nice-1-a7-62-147-78-165.dial.proxad.net ([62.147.78.165]:21253 "EHLO monpc") by vger.kernel.org with ESMTP id S270687AbTGNPXZ (ORCPT ); Mon, 14 Jul 2003 11:23:25 -0400 From: Guillaume Chazarain To: Con Kolivas Cc: linux-kernel@vger.kernel.org, phillips@arcor.de, smiler@lanil.mine.nu Date: Mon, 14 Jul 2003 17:40:04 +0200 X-Priority: 3 (Normal) Message-Id: Subject: Re: [RFC][PATCH] SCHED_ISO for interactivity MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" X-Mailer: Opera 6.06 build 1145 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 14/07/03 02:07:34, Con Kolivas 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