lkml.org 
[lkml]   [2001]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [linux-audio-dev] low-latency scheduling patch for 2.4.0


David Woodhouse wrote:

> jadb@redhat.com 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:25    [W:0.362 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site