Re: 2.4.10-ac10-preempt lmbench output.

safemode (safemode@speakeasy.net)
Wed, 10 Oct 2001 08:00:04 -0400


OK, i copied the mp3 into /dev/shm and without any renicing of anything it
plays fine during dbench 32. so the problem is disk access taking too long.

Which is strange since i'm running dbench on a separate hdd on a totally
different controller.

On Wednesday 10 October 2001 07:41, safemode wrote:
> On Wednesday 10 October 2001 01:26, Andrea Arcangeli wrote:
> > On Tue, Oct 09, 2001 at 10:13:58PM -0700, Andrew Morton wrote:
> > >
> > > Oh. And always remember to `renice -19' your X server.
>
> Blah, You shouldn't need to. You shouldn't have anything able to lag your
> X server unless you're running so many programs your cpu time slices are
> too small for it's needs ( or memory).
>
> > I don't renice my X server (I rather renice all cpu hogs to +19 and I
> > left -20 for something that really needs to run as fast as possible
> > regardless of the X server).
> >
> > Andrea
>
> freeamp runs with no noticable cpu usage, meaning it's 0.0 nearly 100% of
> the time and i have 256K of input buffer and 16K of output. Then i have a
> process like dbench create a bunch of threads (32) and cause freeamp to
> skip. Now how is that a fair spread of cpu? The point is that this doesn't
> have to do with cpu spread and getting locked out of cpu. It just has to
> do with dbench holding the kernel for too long in places and the kernel
> should know that and tell it to wait since other processes are behaving.
> There needs to be a threshhold of kernel usage before the kernel will begin
> to preempt that task for all the ones within the threshhold unless YOU want
> that kernel hogger to run at full speed. In which case you can renice it to
> a lower nice (higher priority). Dbench is getting it's share of cpu maybe,
> but it's getting for too much of it's share of kernel time and that needs
> to be stopped and it's unfair in a multi-user multiprocessing system.
> That's what i meant earlier.
>
> It's just my opinion that kernel hoggers should need to be given user
> defined higher priority to hog the kernel and not everything else to just
> run because you're running a kernel hogger.
-
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/