Re: RT patch acceptance

[Ingo Molnar <mingo@elte.hu>]

* 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.  
And yes, it is still fully correct because all IRQs are threaded - so 
all the scheduling has been 'flattened' and can be controlled. That's 
one reason why IRQ and softirq threading is central to the design of 
PREEMPT_RT.

that's also how PREEMPT_RT can reach sub-20-usec _worst-case_ 
rescheduling latencies using generic workloads (i.e. system swapping to 
death doing heavy IDE IO and DMA and networking and _still_ not having 
larger than 10 usecs worst-case latencies!). This is also why your 
earlier 'driver latencies' arguments are wrong as well. Think about it 
Andrea, this is a key property of PREEMPT_RT.

(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.)

[ I'd really prefer if some of the armchair RT experts would actually
  check out PREEMPT_RT, would contribute code, testing or ideas, and 
  generally would attempt to be productive, would attempt to be nice to 
  each other - instead of blasting a project they first saw a few days
  ago when a flamewar got large enough on lkml.  I've not said (or even
  thought) a single bad thing about any other project, i'm just running
  my own. So get a life, date a girl and have some fun and stuff =:-) ]

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