On Sat, Apr 08, 2006 at 09:25:30AM +0200, Ingo Molnar wrote:
> > to the contrary, the "RT overload" code in the -rt tree does strict,
> > system-wide RT priority scheduling. That's the whole point of it.
>
> so after this "clarification of terminology" i hope you are in picture
> now, so could you please explain to me what you meant by:
> > > You should consider for a moment to allow for the binding of a
> > > thread to a CPU to determine the behavior of a SCHED_FIFO class task
> > > instead of creating a new run category. [...]
>
> to me it still makes no sense, and much of the followups were based on
> this. Or were you simply confused about what the scheduling code in -rt
> does precisely? Did that get clarified now?
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.
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.
bill
-
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]
