Messages in this thread |  | | | Date | Mon, 11 Oct 2004 23:54:20 +0200 | | From | Ingo Molnar <> | | Subject | Re: [ANNOUNCE] Linux 2.6 Real Time Kernel |
| |
* Sven Dietrich <sdietrich@mvista.com> wrote:
> IMO the number of raw_spinlocks should be lower, I said teens before. > > Theoretically, it should only need to be around hardware registers and > some memory maps and cache code, plus interrupt controller and other > SMP-contended hardware.
yeah, fully agreed. Right now the 90 locks i have means roughly 20% of all locking still happens as raw spinlocks.
But, there is a 'correctness' _minimum_ set of spinlocks that _must_ be raw spinlocks - this i tried to map in the -T4 patch. The patch does run on SMP systems for example. (it was developed as an SMP kernel - in fact i never compiled it as UP :-|.) If code has per-CPU or preemption assumptions then there is no choice but to make it a raw spinlock, until those assumptions are fixed. > There are some concurrency issues in kernel threads, and I think there > is a lot of work here. The abstraction for LOCK_OPS is a good > alternative, but like the spin_undefs, its difficult to tell in the > code whether you are dealing with a mutex or a spinlock.
what do you mean by 'it's difficult to tell'? In -T4 you do the choice of type in the data structure and the API adapts automatically. If the type is raw_spinlock_t then a spin_lock() is turned into a _raw_spin_lock(). If the type is spinlock_t then the spin_lock() is redirected to mutex_lock(). It's all transparently done and always correct.
> There are a whole lot of caveats and race conditions that have not yet > been unearthed by the brief LKML testing. [...]
actually, have you tried your patchset on an SMP box? As far as i can see the locking in it ignores SMP issues _completely_, which makes the choice of locks much less useful.
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/
|  |