Actually Bill Davidsen wrote, now 2nd level indent...
> Bill Davidsen suggested:
> > <bias report, I do stuff on servers a lot> It might be that the total
> > interactivity bonus should be set for a system, so that the admin trying
> > to use and editor on a config file wouldn't have an unresponsive cursor,
> > while a bunch of users doing similar things would get a smaller (perhaps
> > tiny) bonus and not impact the server main application.
> >
> > Question for the VM gods, faced with memory pressure should the VM as well
> > as the schedular be aware of interactivity and give a preference to those
> > processes when deciding what to page out? The supreme court says it's okay
> > to give preference as long as it's not a quota ;-)
>
> Maybe we should give a quota. When faced with 100% CPU usage,
> non-server apps, (however you define that), can't, in total, have more
> than 10% CPU, (but see * below).
I was thinking of total priority points... say for example on a server you
have max 50 interactivity points to share between and deserving processes.
So if I'm running vi and only vi it can get up to 100. I'm thinking of the
priority shown by ps, clearly one process will NOT get that much!
If I have X up and run vi in a window, or do web admin, I'd have more
processes and the max for any one would be lower.
In truth I think 50 sounds more like a desktop, maybe 10-20 for a server?
In any case I think that would be easier to track than CPU percentage, and
what I want to change is who gets the CPU next, not how much they get.
Typing in vi takes nada, but I see 1-5 sec delays in echoing the
character, even without X.
If this was to work, I would think that you would care more for xmms not
skipping than windows moving slowly, assuming that was the trade-off.
YMMV.
> *
>
> Is there any reason why we can't set a 90%/10% server/non-server CPU
> limit, but make any application burstable to 100% for no longer than
> 10% of the time? I.E. it would work analogously to a burstable
> network pipe.
Other than I think it's easier to just use the priorities already in place
and diddle them than to track CPU. On the other hand we have CPU and sleep
info. If Ingo or anyone qualified cares enough about this suggestion to
think about it we may get an answer from someone who really knows how this
works.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.- 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/