Messages in this thread | | | Date | Fri, 19 Jun 2009 23:08:39 +0200 | From | Ingo Molnar <> | Subject | Re: [GIT PULL] percpu for 2.6.31 |
| |
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Fri, 19 Jun 2009, Ingo Molnar wrote: > > > > ( Many wont btw: we still dont have lockdep support in all > > architectures - 3 years and counting. It's a highly useful purely > > sw feature with zero hardware dependencies. Fortunately it's > > well-modularized and the functionality is non-essential. Percpu > > allocation is not so lucky as it's essential functionality. ) > > When it coems to code coverage, x86 matters _so_ much more than > any other architecture, that verification features like lockdep > etc are way more important on x86 than on anything else. > > Sure, there may be locking issues in some arch-specific code, and > other architectures could be better off caring. But the advantage > of lockdep for some pissant architecture that has a very limited > user base (maybe lots of chips, but much more limited _use_ - > fewer drivers, fewer workloads etc) is much lower, since those > architectures know that x86 will give them 99% of the coverage. > > So it's quite reasonable to think that other architectures simply > care less.
Hm, agreed, i accept that point. A minimal architecture can be implemented in as little as 10-20 KLOC, and the chances of there being lockups in that code, versus the millions of lines of code they take advantage of, is proportionately low.
Btw., here's the current lockdep support list:
for N in arch/*/; do printf "%30s: %d\n" $N \ $(git grep -l -w LOCKDEP_SUPPORT $N | wc -l); done | \ sort -t: -n -k 2 -r arch/x86/: 1 arch/um/: 1 arch/sparc/: 1 arch/sh/: 1 arch/s390/: 1 arch/powerpc/: 1 arch/mips/: 1 arch/blackfin/: 1 arch/avr32/: 1 arch/arm/: 1 arch/xtensa/: 0 arch/parisc/: 0 arch/mn10300/: 0 arch/microblaze/: 0 arch/m68knommu/: 0 arch/m68k/: 0 arch/m32r/: 0 arch/ia64/: 0 arch/h8300/: 0 arch/frv/: 0 arch/cris/: 0 arch/alpha/: 0
Lockdep is supported on 10 architectures, not supported on 12.
We still have regular friction between pre-lockdep and post-lockdep APIs, such as local_irq_save / raw_local_irq_save. If some generic code makes use of raw_local_irq_save then non-lockdep architectures break and the 'offending' tree gets excluded from linux-next.
So there's ongoing cost involved for the core kernel as well and non-lockdep architectures dont just hurt themselves, they also hurt core kernel changes, via their incomplete APIs. Such assymetries could be eliminated without adding lockdep support, by providing 1:1 aliases - but not even this minimal step is done as there's basically no incentive on the part of these architectures to do it.
Taking advantage of other trees while costing them - that looks a bit like parasitic behavior to me, in this specific instance of lockdep support - wouldnt you agree to a certain degree?
Ingo
| |