Messages in this thread | | | From | safemode <> | Subject | Re: 2.4.10-ac10-preempt lmbench output. | Date | 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/
| |