Re: RT patch acceptance

[Andrea Arcangeli <andrea@suse.de>]

On Wed, Jun 01, 2005 at 04:19:19PM +0200, Ingo Molnar wrote:
> 
> * Andrea Arcangeli <andrea@suse.de> wrote:
> 
> > I've a bug in my queue that definitely would break preempt-RT:
> >
> >       BUG xxx : spends excessive time with interrupts disabled on large memory>
>        systems
> >
> > workaround:
> >
> >       #define MAX_ITERATION 100000
> >       if ((nr_pages > MAX_ITERATION) && !(nr_pages % MAX_ITERATION)) {
> >               spin_unlock_irq(&zone->lru_lock);
> >               spin_lock_irq(&zone->lru_lock);
> >       }
> 
> you are wrong. This codepath is not running with interrupts disabled on 
> PREEMPT_RT. irqs-off spinlocks dont turn off interrupts on PREEMPT_RT.  

Then I'm afraid preempt-RT infringe on the patent that they take after
years of doing that in linux. I'm not a lawyer but you may want to
check before investing too much on this for the next 15 years. The
nanokernel thing has happened exactly because they couldn't wrap the cli
calls to do something different than a cli AFIK. Nanokernel was a nice
workaround to avoid having to us the patented irq disable redefine.

I assumed you weren't infringing on the patent and in turn disabling irq
locally would actually do that, sorry.

> (there are still some ways to introduce latencies into PREEMPT_RT, but 
> they are not common and we are working on ways to cover them all.)

How can you schedule a task while a spinlock is held? Ok irqs will keep
going, but how can you reschedule risking to deadlock? As long as there
are regular spinlocks in any driver out there (i.e. all of them) then
you can still introduce latencies. It doesn't seem too uncommon to me to
take a spinlock. Preempt-rt reliability cannot be remotely compared to
RTAI.