Messages in this thread | | | Date | Thu, 31 Jul 2003 14:19:58 -0700 | From | William Lee Irwin III <> | Subject | Re: 2.6.0-test2-mm1 results |
| |
At some point in the past, Con Kolivas wrote: >> How do we get around this? I'll be brave here and say I'm not sure >> we need to, as cpu hogs have a knack of slowing things down for >> everyone, and it is best not just for interactivity for this to >> happen, but for fairness.
On Thu, Jul 31, 2003 at 08:19:01AM -0700, Martin J. Bligh wrote: > Well, what you want to do is prioritise interactive tasks over cpu hogs. > What *seems* to be happening is you're just switching between cpu hogs > more ... that doesn't help anyone really. I don't have an easy answer > for how to fix that, but it doesn't seem desireable to me - we need some > better way of working out what's interactive, and what's not.
I don't believe so. You're describing the precise effect of finite- quantum FB (or tiny quantum RR) on long-running tasks. Generally multilevel queues are used to back off to a service-time dependent queueing discipline (e.g. use RR with increasing quanta for each level and use level promotion and demotion to discriminate interactive tasks, which remain higher-priority since overall policy is FB) with longer timeslices for such beasts for less context-switching overhead. I say lengthen timeslices with service time and make priority preemption work.
-- wli - 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/
| |