Re: RT patch acceptance

[Sven-Thorsten Dietrich <sdietrich@mvista.com>]

On Thu, 2005-05-26 at 13:52 -0700, Bill Huey wrote:


> > But I always though we should have a new lock type that is between
> > spinlocks and semaphores and is less heavyweight than a semaphore
> > (which tends to be quite slow due to its many context switches). Something
> > like a spinaphore, although it probably doesnt need full semaphore
> > semantics (rarely any code in the kernel uses that anyways). It could
> > spin for a short time and then sleep. Then convert some selected
> > locks over. e.g. the mm_sem and the i_sem would be primary users of this.
> > And maybe some of the heavier spinlocks.
> 
> Adaptiving spinning is a difficult thing to do since you have to snoop
> for the active "current" on other processors to determine if you have to
> sleep or not. FreeBSD 5.x uses this stuff and the locking code is very
> complicated. In the future, it maybe desirable to incorporate parts of
> this functionality into another RT mutex implementation. The current one
> is overloaded enough with functionality as is .
> 

> > If you drop irq threads then you cannot convert all locks
> > anymore or have to add ugly in_interrupt()checks. So any conversion like
> > that requires converting locks.
> 
> That's reversed. Interrupt threads are an isolated change itself and can
> be submitted upstream if so desired with no associated lock changes.
> But that paragraph above is rather vague, so I can only guess at what you're
> talking about. There are ways of doing context stealing with irq-threads to
> minimize overhead and the FreeBSD folks have partially implemented this from
> my memory.
> 
> bill
> 

-
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/