lkml.org 
[lkml]   [2003]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] O6int for interactivity
Date
On Thu, 17 Jul 2003 10:35, Davide Libenzi wrote:
> On Thu, 17 Jul 2003, Con Kolivas wrote:
> > > > + p->sleep_avg = (p->sleep_avg * MAX_BONUS / runtime + 1)
> >
> > * runtime /
> >
> > > MAX_BONUS;
> > >
> > > I don't have the full code so I cannot see what "runtime" is, but if
> > > "runtime" is the time the task ran, this is :
> > >
> > > p->sleep_avg ~= p->sleep_avg + runtime / MAX_BONUS;
> > >
> > > (in any case a non-decreasing function of "runtime" )
> > > Are you sure you want to reward tasks that actually ran more ?
> >
> > That was the bug. Runtime was supposed to be limited to MAX_SLEEP_AVG.
> > Fix will be posted very soon.
>
> Con, it is not the limit. You're making sleep_avg a non-decreasing
> function of "runtime". Basically you are rewarding tasks that did burn
> more CPU (if runtime is what the name suggests). Are you sure this is what
> you want ?

It's not cpu runtime; it is time since starting the process.

>
> > > Con, you cannot follow the XMMS thingy otherwise you'll end up bolting
> > > in the XMMS sleep->burn pattern and you'll probably break the
> > > make-j+RealPlay for example. MultiMedia players are really tricky since
> > > they require strict timings and forces you to create a special
> > > super-interactive treatment inside the code. Interactivity in my box
> > > running moderate high loads is very good for my desktop use. Maybe
> > > audio will skip here (didn't try) but I believe that following the
> > > fix-XMMS thingy is really bad. I believe we should try to make the
> > > desktop to feel interactive with human tollerances and not with strict
> > > timings like MM apps. If the audio skips when dragging like crazy a X
> > > window using the filled mode on a slow CPU, we shouldn't be much
> > > worried about it for example. If audio skip when hitting the refresh
> > > button of Mozilla, then yes it should be fixed. And the more you add
> > > super interactive patterns, the more the scheduler will be exploitable.
> > > I recommend you after doing changes to get this :
> > >
> > > http://www.xmailserver.org/linux-patches/irman2.c
> > >
> > > and run it with different -n (number of tasks) and -b (CPU burn ms
> > > time). At the same time try to build a kernel for example. Then you
> > > will realize that interactivity is not the bigger problem that the
> > > scheduler has right now.
> >
> > Please don't assume I'm writing an xmms scheduler. I've done a lot more
> > testing than xmms.
>
> Ok, I'm feeling better already ;)

Me too :)

Con

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.081 / U:0.820 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site