Re: RT patch acceptance

[Andrea Arcangeli <andrea@suse.de>]

On Wed, Jun 01, 2005 at 01:18:54PM +0100, Paulo Marques wrote:
> It seems you didn't follow that thread too closely :)

True, not yet. But trust me I've seen many times the kernel hanging
preventing scheduling, despite ping was still doing fine ;).

> This wouldn't affect real-time tasks running over preempt-RT at all, 
> since the interactive bonus would never be enough to go over real-time 
> priority tasks.

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);
	}

Measurements wouldn't necessary catch that bug, unless they were running
the same workload with the same amount of ram.

Or perhaps Ingo will try to remove all spinlocks from the kernel instead
of creating RT-aware spinlocks, dunno. But whatever we change, will have
a performance impact for the fast path (but perhaps not measurable).

> I do understand the point you're trying to make about the simplicity of 
> a nano-kernel that makes it much more reliable and verifiable.

Exactly, they're simply not remotely comaprable, a VM improvement may
break preempt-RT anytime, it's just too easy to screw things up and
invalidate all "measurements".

> However it seems that the range of applications that can use the 
> nano-kernel approach is getting pretty thin between the applications 
> that are so simple that they can run on a dedicated hardware/processor 
> without any OS at all, and the applications that require more complex 
> services than those that a nanokernel can provide by itself.

Sure, preempt-RT makes sense (preempt alone doesn't make any sense
IMHO). I'm simply saying that using preempt-RT metal hard is a mistake
when RTAI ruby hard will be much safer and much simpler to use and it
doesn't risk to break at every kernel upgrade.

For other RT apps like audio built on a weak soft-RT API from the ground
using RTAI wouldn't be feasible (at least in the short term).