On Mon, Dec 19, 2005 at 09:11:18PM +0100, Ingo Molnar wrote:
> We humans have a given number of neurons, which form a hard limit :)
That's also a very valid argument for keeping the number of different
locking mechanisms down to a small number.
> we saw that with the genirq code, with the spinlock code, with the
> preempt code. Consolidation did not add anything drastiically new, but
> code consolidation _did_ make things more hackable, and improved the end
> result far more than a splintered set of implementations would have
> looked like.
>
> Just look at the semaphore implementations of various architectures,
> it's a quite colorful and inconsistent mix. Can you imagine adding
> deadlock debugging to each of them?
However, the argument _against_ making things generic is that they
become less optimised for specific architectures. I'm still not
convinced that the genirq stuff is as optimal for ARM as the existing
code is, so I've little motivation to move to the genirq stuff.
(Though I will try to make things easier for those who would like to.)
The same argument applies to attempts to make atomic ops generic using
cmpxchg as a basis for that (as demonstrated on "that other list"), and
the fast path of semaphores.
On "that other list", we're debating saving between 9 and 13 CPU
cycles as an argument in favour of mutexes. Such a gain which could
very probably be wiped out by any attempt to make them "generic".
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
