[PlanetCCRMA] Configuring 2.6.11-0.3.rdt.rhfc2.ccrma for 0 xruns...

[Fernando Lopez-Lezcano]

On Wed, 2005-04-13 at 12:41, Mark Knecht wrote: 
> On 13 Apr 2005 11:44:53 -0700, Fernando Lopez-Lezcano
> <nando@ccrma.stanford.edu> wrote:
> > On Wed, 2005-04-13 at 11:28, Mark Knecht wrote:
> 
> > > 1) Is any of this chrt stuff sticky? Or is this something I'd have to
> > > do every time I boot?
> > 
> > If you change stuff you have to do that every boot. "Rtirq" is already
> > reordering stuff on its own so that the soundcards have higher priority
> > than the rest.
> > 
> > > 2) What is 'fifo priority'?
> > 
> > That is technically SCHED_FIFO, the realtime priority scheduler classer
> > (all "normal" processes are in the SCHED_OTHER class, SCHED_FIFO
> > processes have priority over SCHED_OTHER tasks no matter what, and once
> > they get the cpu they run until they voluntarily relinquish the cpu -
> > that's how jack and its clients run).
> 
> OK. Now, what I'm seeing is that every IRQ process is SCHED_FIFO:
> 
> [root@Godzilla root]# chrt -p 1151
> pid 1151's current scheduling policy: SCHED_FIFO
> pid 1151's current scheduling priority: 60
> [root@Godzilla root]# chrt -p 20
> pid 20's current scheduling policy: SCHED_FIFO
> pid 20's current scheduling priority: 59
> [root@Godzilla root]# chrt -p 344
> pid 344's current scheduling policy: SCHED_FIFO
> pid 344's current scheduling priority: 50
> [root@Godzilla root]# chrt -p 411
> pid 411's current scheduling policy: SCHED_FIFO
> pid 411's current scheduling priority: 42
> [root@Godzilla root]#
> 
> Do we really want it that way?

yes, all of them should be SCHED_FIFO.

> > > 3) Which way is 'higher priority'? 80 or 37.
> > 
> > 100 is highest
>
> [root@Godzilla root]# chrt -m
> SCHED_FIFO min/max priority     : 1/99
> SCHED_RR min/max priority       : 1/99
> SCHED_OTHER min/max priority    : 0/0
> [root@Godzilla root]#
> 
> > 
> > Strange. It could be that rtirq is running before all the sound modules
> > are loaded. What happens if you run "rtirq stop" and "rtirq start" after
> > the boot is complete? Does that change the priorities?
> > 
> > > I've tried changing dirty_expire_centisecs to 1000 and started a new
> > > copy. 2 minutes in and no xruns so far at 128/2, but I'll need to go
> > > the full 20 minutes to have more confidence. After that I'll try 64/2.
> > 
> > So that is the reason for your xruns. "1000" was just a suggestion, not
> > what you have to use, you can try using lower values.
> 
> No. You know how statistical stuff is, correct? As soon as you say one
> thing then the other starts happening. 

Engineering tradeoff, of course. It depends on what is more important,
load or frequency of updaters. But of course all the vm stuff is tricky
so it is probably not so easy to tune. 

> With that test it went about
> 5-8 minutes with no xruns, but then from 8-22 minutes I got a large
> number of xruns. It actually came out worse than the 3000 setting,
> although I ran each copy only once so I'm not sure what it proves.
> 
> Now, I thought I'd saved the message from either Leee Ravell or Ingo
> Molnar about this. I do this on the laptop that was working so well
> but was not doing here on my Planet box with your kernel. I just tried
> it. The whole 20 minute, 21GB copy ran perfectly with no xruns at
> 128/2. Set the HDSP interrupt to non-threaded operation:
> 
> [root@Godzilla root]# echo "0" > /proc/irq/9/hdsp/threaded
> 
> With this I'm getting good, no very good or great, results.
> 
> I pointed this out to Ryan Gallager some time back and he did it for
> his USB devices and got good results. I had asked you about this (or I
> think I did) as few days back but it seemed like you thought it wasn'
> t appropriate for this kernel? Did I get that wrong? Is there any
> reason you know of not to use this? 

Not that I can think of. 

> As I say, I think it was Ingo who
> told me to try it back when I was having trouble with ACPI and USB
> mice in October, 04.
> 
> Anyway, perfect results at 128/2. 

Good, maybe this should be something that rtirq should do by default.
Rui: are you reading this thread? Maybe rtirq should set the snd
interrupts to not threaded if it finds the proc controls for that. 

> I'll be trying 64/2 in a few minutes.
> 
> This can be set in rc.local, etc. and works every time I boot up on my
> laptop.

The threaded stuff? Yes, I guess it could go there. It would be best to
incorporate it into rtirq, of course. 

-- Fernando

> > > I do not understand these vm parameters....
> > 
> > Neither do I. I think they tune how the virtual memory subsystem works.
> > The one you are changing tells the system how long to wait between scans
> > of dirty pages (pages that are marked to be written to disk). If that is
> > too long then when the system checks there are a lot of pages to write
> > to disk and that presumably causes the xrun, if you lower that the
> > system checks more often (causing more overhead?) and finds less pages
> > to write to disk.
> > 
> 
> thanks!
> 
> - Mark