Messages in this thread | | | Subject | Re: RT patch acceptance | From | Sven-Thorsten Dietrich <> | Date | Thu, 26 May 2005 14:09:54 -0700 |
| |
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/
| |