Messages in this thread | | | Date | Sat, 8 Apr 2006 10:03:49 +0200 | From | Ingo Molnar <> | Subject | Re: RT task scheduling |
| |
* Bill Huey <billh@gnuppy.monkey.org> wrote:
> The last time I looked at it I thought it did something pretty > simplistic in that it just dumped any RT thread to another CPU but > didn't do it in a strict manner with regard to priority. Maybe that's > changed or else I didn't pay attention to it that as carefully as I > thought.
well as Darren's testcase shows, it might still have some bug - but the mechanism is intended to be strict. (the implementation had a couple of strictness bugs (they show up as long latencies on SMP) but those were ironed out months ago.)
> As far as CPU binding goes, I'm wanting a method of getting around the > latency of the rt overload logic in certain cases at the expense of > rebalancing. That's what I ment by it.
yeah, that certainly makes sense, and it's one reason why i'm thinking about the separate SCHED_FIFO_GLOBAL policy for 'globally scheduled' RT tasks, while still keeping the current lightweight non-global RT scheduling. Global scheduling either means a global lock, or as in the -rt implementation means a "global IPI", but there's always a nontrivial "global" cost involved.
Ingo - 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/
| |