On Tue, 2007-04-10 at 07:23 -0400, Ed Tomlinson wrote:
> On Monday 09 April 2007 22:39, Mike Galbraith wrote:
> > On Mon, 2007-04-09 at 07:38 +0200, Mike Galbraith wrote:
> >
> > > I don't think you can have very much effect on latency using nice with
> > > SD once the CPU is fully utilized. See below.
> > >
> > > /*
> > > * This contains a bitmap for each dynamic priority level with empty slots
> > > * for the valid priorities each different nice level can have. It allows
> > > * us to stagger the slots where differing priorities run in a way that
> > > * keeps latency differences between different nice levels at a minimum.
> > > * ie, where 0 means a slot for that priority, priority running from left to
> > > * right:
> > > * nice -20 0000000000000000000000000000000000000000
> > > * nice -10 1001000100100010001001000100010010001000
> > > * nice 0 0101010101010101010101010101010101010101
> > > * nice 5 1101011010110101101011010110101101011011
> > > * nice 10 0110111011011101110110111011101101110111
> > > * nice 15 0111110111111011111101111101111110111111
> > > * nice 19 1111111111111111111011111111111111111111
> > > */
> > >
> > > Nice allocates bandwidth, but as long as the CPU is busy, tasks always
> > > proceed downward in priority until they hit the expired array. That's
> > > the design.
> >
> > There's another aspect of this that may require some thought - kernel
> > threads. As load increases, so does rotation length. Would you really
> > want CPU hogs routinely preempting house-keepers under load?
>
> SD has a schedule batch nice level. This is good for tasks that want lots
> of cpu when they can get it. If you overload your cpu I expect the box
> to slow down - including kernel threads. If really required they can be
> started with a higher priority...
Sure. Anything that is latency sensitive, and those kernel threads that
are necessary for system function can be made RT to bypass the designed
in latency. It's just another thing that should be considered before
integration. Now if burst loads (only one of which it the desktop)
would just cease to exist...
-Mike
-
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]
