On Friday 20 April 2007 05:26, Ray Lee wrote:
> On 4/19/07, Con Kolivas <[email protected]> wrote:
> > The one fly in the ointment for
> > linux remains X. I am still, to this moment, completely and utterly
> > stunned at why everyone is trying to find increasingly complex unique
> > ways to manage X when all it needs is more cpu[1].
>
> [...and hence should be reniced]
>
> The problem is that X is not unique. There's postgresql, memcached,
> mysql, db2, a little embedded app I wrote... all of these perform work
> on behalf of another process. It's just most *noticeable* with X, as
> pretty much everyone is running that.
>
> If we had some way for the scheduler to decide to donate part of a
> client process's time slice to the server it just spoke to (with an
> exponential dampening factor -- take 50% from the client, give 25% to
> the server, toss the rest on the floor), that -- from my naive point
> of view -- would be a step toward fixing the underlying issue. Or I
> might be spouting crap, who knows.
>
> The problem is real, though, and not limited to X.
>
> While I have the floor, thank you, Con, for all your work.
You're welcome and thanks for taking the floor to speak. I would say you have
actually agreed with me though. X is not unique, it's just an obvious so
let's not design the cpu scheduler around the problem with X. Same goes for
every other application. Leaving the choice to hand out differential cpu
usage when they seem to need is should be up to the users. The donation idea
has been done before in some fashion or other in things like "back-boost"
which Linus himself tried in 2.5.X days. It worked lovely till it did the
wrong thing and wreaked havoc. As is shown repeatedly, the workarounds and
the tweaks and the bonuses and the decide on who to give advantage to, when
done by the cpu scheduler, is also what is its undoing as it can't always get
it right. The consequences of getting it wrong on the other hand are
disastrous. The cpu scheduler core is a cpu bandwidth and latency
proportionator and should be nothing more or less.
--
-ck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
