Re: 2.4.10-ac10-preempt lmbench output.

[Andrea Arcangeli <andrea@suse.de>]

On Tue, Oct 09, 2001 at 10:09:33PM -0400, safemode wrote:
> On Tuesday 09 October 2001 21:18, Andrea Arcangeli wrote:
> > On Tue, Oct 09, 2001 at 08:36:56PM -0400, safemode wrote:
> > > mp3 player to skip, though.   That probably wont be fixed intil 2.5,
> > > since you need to have preemption in the vm and the rest of the kernel.
> >
> > xmms skips during I/O should have nothing to do with preemption.
> >
> > As Alan noted for the ring of dma fragments to expire you need a
> > scheduler latency of the order of seconds, now (assuming the ll points
> > in read/write paths) when we've bad latencies under writes it's of the
> > order of 10msec and it can be turned down further by putting preemption
> > checks in the buffer lru lists write paths.
> >
> > The reason xmms skips I believe is because the vm is doing write
> > throttling. I've at least one idea on how to fix it but it has nothing
> > to do with preemption in the VM or whatever else scheduler related
> > thing.
> >
> > So I wouldn't expect to fix any playback skips where buffering is
> > possible by using the preemptive patch etc.. It's nearly impossible that
> > it makes any difference.
> >
> > The preemptive patch can matter only if you're doing real time signal
> > processing where any kind of buffering isn't possible.
> >
> > Andrea
> 
> That's what i would think too at first.  What's confusing me is the fact that 
> it is affected by priority.  Which means preemption can solve the problem.  
> If i run the mp3 player at nice -n -20, i get no skips.   Why else would that 

As Dan Mann noted privately there's of course also the possibility that
the scheduler scheduled xmms away for a long time because there's a very
high cpu load, this seems confirmed since the skip goes away with nice
-n -20.

> be if not that preemption is dictating that freeamp's process gets whatever 
> it wants when it wants ?   

If -n -20 fixes the problem that has nothing to do with scheduler
latency or with the write throttling and the preemption patch cannot
help at all.

If -n -20 fixes the problem it simply means your cpu load was too high.
The linux scheduler is fair. So to fix it there are only those possible
ways:

1) buy a faster cpu
2) add additional cpus to your system
3) reduce the cpu load of your system by stopping some of the cpu
   eaters
4) run xmms RT or with higher priority (or reduce the priority of the
   other cpu hogs)

As said it's very very unlikely that preemption points can fix xmms
skips anyways, the worst scheduler latency is always of the order of the
msecs, to generate skips you need a latency of seconds.

I thought your problem weren't just xmms being scheduled away due high
cpu load, because dbench is intended to be an I/O benchmark but maybe
you've lots of cache and you do little I/O?

The problem I was talking about in my earlier email applies to RT tasks
too, so if you were doing lots of I/O and xmms started doing write
throttling just running nice -n -20 wouldn't helped.

> I mean, if renicing the process allows it not to skip, what else is going on 

The reason it allows it not to skip is because the scheduler gives more
cpu to xmms.

There's nothing magic in the software, if you divide the cpu in 10 parts
and you give 1/10 of the cpu to xmms, but xmms needs 1/2 of the cpu to
play your .mp3 then there's nothing you can do to fix it but to tell
the scheduler to give more cpu to xmms (renicing to -20 gives more cpu
to xmms, enough to sustain the .mp3 decoding without dropouts).

> Ok, so maybe i'm wrong and it has nothing to do with preemption, if then what 

Correct, it has nothing to do with preemption.

> not at normal 0.   And why is that the default behavior of the kernel ?  It 
> seems quite unfair in a multiuser-multiprocessing system. 

The opposite, the scheduler is fair, so it divides the cpu to all the
tasks in your system. If xmms wouldn't skip the scheduler isn't fair,
and as you say that would be very bad in a multiuser system.

Andrea