[lkml]   [2003]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] O6int for interactivity
    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 :
    > >
    > >
    > >
    > > 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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:46    [W:0.021 / U:5.632 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site