lkml.org 
[lkml]   [2006]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: interactive task starvation
    Date
    On Wednesday 22 March 2006 01:01, Mike Galbraith wrote:
    > On Wed, 2006-03-22 at 00:45 +1100, Con Kolivas wrote:
    > > I give up. Add as many tunables as you like in as many places as possible
    > > that even less people will understand. You've already told me you'll be
    > > running 0,0.
    >
    > Instead of giving up, how about look at the code and make a suggestion
    > for improvement? It's not an easy problem, as you're well aware.
    >
    > I really don't see why you're (seemingly) getting irate. Tunables for
    > this are no different that tunables like CHILD_PENALTY etc etc etc. How
    > many casual users know those exist, much less understand them?

    Because I strongly believe that tunables for this sort of thing are wrong.
    CHILD_PENALTY and friends have never been exported apart from out-of-tree
    patches. These were meant to be tuned in the kernel and never exported. Ingo
    didn't want *any* tunables so I'm relatively flexible with an on/off switch
    which he doesn't like. I really do believe most users will only have it on or
    off though.

    Don't think I'm ignoring your code. You inspired me to do the original patches
    3 years ago.

    I have looked at your patch at length and basically what it does is variably
    convert the interactive estimator from full to zero over some timeframe
    choosable with your tunables. Since most users will use either full or zero I
    actually believe the same effect can be had by a tiny modification to
    enable/disable the estimator anyway. This is not to deny you've done a lot of
    work and confirmed that the estimator running indefinitely unthrottled is
    bad. What timeframe is correct to throttle is impossible to say
    though :-( Most desktop users would be quite happy with indefinite because
    they basically do not hit workloads that "exploit" it. Most server/hybrid
    setups are willing to sacrifice some interactivity for fairness, and the
    basic active->expired design gives them enough interactivity without
    virtually any boost anyway. Ironically, audio is fabulous on such a design
    since it virtually never consumes a full timeslice.

    So any value you place on the timeframe as the default ends up being a
    compromise, and this is what Ingo is suggesting. This is similar to when
    sleep_avg changed from 10 seconds to 30 seconds to 2 seconds at various
    times. Luckily the non linear decay of sleep_avg circumvents that being
    relevant... but it also leads to the exact issue you're trying to fix. Once
    again we're left with choosing some number, and as much as I'd like to help
    since I really care about the desktop, I don't think any compromise is
    correct. Just on or off.

    Cheers,
    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: 2006-03-21 15:21    [W:0.128 / U:33.248 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site