Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

[Joe deBlaquiere]

David Woodhouse wrote:

> [e-mail] said:
> 
>> (If you're running a program XIP from flash and a  RT interrupt leaves
>> the flash in a unreadable state, boom!).
> 
> 
> Bad example. I don't expect Linux to support writable XIP any time in the 
> near future. The only thing I envisage myself doing to help people who want 
> writable XIP is to take away their crackpipe.
> 

I wasn't thinking of running the kernel XIP from writable, but even 
trying to do that from the filesystem is a mess. If you're going to be 
that way about it...

/me hands over the crackpipe

> Until we get dual-port flash, of course.
> 
> The thing that really does concern me about the flash driver code is the
> fact that it often wants to wait for about 100µs. On machines with
> HZ==100, that sucks if you use udelay() and it sucks if you schedule(). So
> we end up dropping the spinlock (so at least bottom halves can run again)
> and calling:
> 
> static inline void cfi_udelay(int us)
> {
>         if (current->need_resched)
>                 schedule();
>         else
>                 udelay(us);
> }
> 

The locical answer is run with HZ=10000 so you get 100us intervals, 
right ;o). On systems with multiple hardware timers you could kick off a 
single event at 200us, couldn't you? I've done that before with the 
extra timer assigned exclusively to a resource. It's not a giant time 
slice, but at least you feel like you're allowing something to happen, 
right?

> 
> --
> dwmw2

-- 
Joe