* Bill Huey <[email protected]> wrote:
> On Fri, Apr 07, 2006 at 11:19:46AM +0200, Ingo Molnar wrote:
> > -ENOPARSE. CPU binding brings with itself obvious disadvantages that
> > some applications are not ready to pay. CPU binding restricts the
> > scheduler from achieving best resource utilization. That may be fine for
> > some applications, but is not good enough for a good number of
> > applications. So in no way can any 'CPU binding mechanism' (which
> > already exists in multiple forms) replace the need and desire for a
> > globally scheduled class of RT tasks.
>
> You're discussing a different problem than what I'm talking about.
> [...]
no, i'm discussing precisely the point you raised:
>>> 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. [...]
with the observation that 1) binding is already possible [so your
suggestion is apparently knocking on open doors] 2) binding is a
separate mechanism (not adequate for all workloads) and it is thus
orthogonal to what i'm trying to achieve with the "RT overload" stuff.
Really simple and straightforward observations i think.
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]
