On Thu, Apr 19, 2007 at 12:26:03PM -0700, 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.
But for most of those apps, we don't actually care if they do fairly degrade in performance as other loads on the system ramp up. However the user prefers X to be given priority in these situations. Whether that is the design of X, x clients, or the human condition really doesn't matter two hoots to the scheduler. > 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. Firstly, lots of clients in your list are remote. X usually isn't. However for X, a syscall or something to donate time might not be such a bad idea... but given a couple of X clients and a server against a parallel make, this is probably just going to make the clients slow down as well without giving enough priority to the server. X isn't special so much because it does work on behalf of others (as you said, lots of things do that). It is special simply because we _want_ rendering to have priority of the CPU (if you shifed CPU intensive rendering to the clients, you'd most likely want to give them priority to); nice, right? - 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/
