Re: RT patch acceptance

[Bill Huey (hui) <bhuey@lnxw.com>]

On Wed, Jun 01, 2005 at 09:59:05PM +0200, Andrea Arcangeli wrote:
> There's a significant number of local_irq_disable across the kernel, I
> don't see why should we risk a driver update possibly looping a bit too
> logn, to break the RT guarantee. It's not too hard to reach the hundred
> usec range when doing hardware operations in inefficient drivers when
> touchign the mmio/io regions. That would not be a bug in any config but
> preempt-RT. Possibly not nice, but not a bug (keep in mind the usb irq
> in my firewall for whatever reasons keeps irq disabled for >1msec).

Please survey this and see how the patch deals with it. Please also
stop asking FUD enabling questions until you look at the patch.

> Using cli by hand never happens anywhere, while if you grep for
> local_irq_disable that happens in many drivers.

Memory allocators and the like need do to this and this has been dealt
with in the patch. The use of those function isn't SMP safe in drivers,
so any use of those functions and spin-waiting so far has already been
reviewed and dealt with in the patch.

> Using cli in asm is like doing memset() all over the ram... then kernel
> will crash and irq will stop too ;) While local_irq_disable os far was a
> supported API for drivers and generic kernel code (most commmonly used
> before touching per-cpu data structures, so very common in certain part
> of the kernels, including the scheduler).

Some of that stuff has been moved into work queues that are used to
defer processing out-of-line, so that it doesn't effect that path.

Just about all you've been saying has been handled by the patch and I
ask you to stop asking stupid question until you've looked at it..

bill