* Bill Huey <[email protected]> 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 [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]
