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 ?
> > 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 ;)
- Davide
-
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/
This archive was generated by hypermail 2b29 : Wed Jul 23 2003 - 22:00:27 EST