Re: RT patch acceptance

Ingo Molnar
2005-06-01T14:24:37Z

* 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