[GIT PULL] percpu for 2.6.31

[GIT PULL] percpu for 2.6.31

[Tejun Heo]

Hello, Linus.

Please pull from percpu-for-linus git tree from:

    git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu.git for-linus

This contains two logical changes 1. convert most archs to dynamic
percpu allocator and 2. fix x86 lpage allocator and re-enable it.
Both have been posted multiple times and shouldn't break most of the
popular archs.  One known breakage is on parisc which Kyle agreed to
fix post merge.

Ingo, does this look okay to you?  If so, I'll create for-next branch
with the rest of patches and also push other percpu changes through it
(Rusty's drop prefix patches and Christoph's this_cpu_* patches) and
publish it to linux-next.

Thanks.

 Documentation/kernel-parameters.txt              |    6 +
 arch/alpha/include/asm/percpu.h                  |  101 +---------
 arch/alpha/include/asm/tlbflush.h                |    1 +
 arch/arm/kernel/smp.c                            |    4 +-
 arch/arm/mach-kirkwood/cpuidle.c                 |    2 +-
 arch/avr32/kernel/cpu.c                          |    2 +-
 arch/blackfin/mach-common/smp.c                  |    2 +-
 arch/blackfin/mm/sram-alloc.c                    |   22 +-
 arch/cris/include/asm/mmu_context.h              |    3 +-
 arch/cris/mm/fault.c                             |    2 +-
 arch/ia64/Kconfig                                |    3 +
 arch/ia64/kernel/crash.c                         |    2 +-
 arch/ia64/kernel/smp.c                           |    4 +-
 arch/ia64/kernel/traps.c                         |    2 +-
 arch/ia64/kvm/kvm-ia64.c                         |    2 +-
 arch/ia64/sn/kernel/setup.c                      |    2 +-
 arch/ia64/xen/irq_xen.c                          |   24 ++--
 arch/mips/kernel/cevt-bcm1480.c                  |    6 +-
 arch/mips/kernel/cevt-sb1250.c                   |    6 +-
 arch/mips/kernel/topology.c                      |    2 +-
 arch/mips/sgi-ip27/ip27-timer.c                  |    4 +-
 arch/parisc/kernel/irq.c                         |    2 +-
 arch/parisc/kernel/topology.c                    |    2 +-
 arch/powerpc/Kconfig                             |    3 +
 arch/powerpc/kernel/cacheinfo.c                  |    2 +-
 arch/powerpc/kernel/process.c                    |    2 +-
 arch/powerpc/kernel/sysfs.c                      |    4 +-
 arch/powerpc/kernel/time.c                       |    6 +-
 arch/powerpc/mm/pgtable.c                        |    2 +-
 arch/powerpc/mm/stab.c                           |    4 +-
 arch/powerpc/oprofile/op_model_cell.c            |    2 +-
 arch/powerpc/platforms/cell/cpufreq_spudemand.c  |    2 +-
 arch/powerpc/platforms/cell/interrupt.c          |    2 +-
 arch/powerpc/platforms/ps3/interrupt.c           |    2 +-
 arch/powerpc/platforms/ps3/smp.c                 |    2 +-
 arch/powerpc/platforms/pseries/dtl.c             |    2 +-
 arch/powerpc/platforms/pseries/iommu.c           |    2 +-
 arch/s390/appldata/appldata_base.c               |    2 +-
 arch/s390/include/asm/percpu.h                   |   32 +---
 arch/s390/kernel/nmi.c                           |    2 +-
 arch/s390/kernel/smp.c                           |    2 +-
 arch/s390/kernel/time.c                          |    4 +-
 arch/s390/kernel/vtime.c                         |    2 +-
 arch/sh/kernel/localtimer.c                      |    2 +-
 arch/sh/kernel/topology.c                        |    2 +-
 arch/sparc/Kconfig                               |    3 +
 arch/sparc/kernel/nmi.c                          |    6 +-
 arch/sparc/kernel/pci_sun4v.c                    |    2 +-
 arch/sparc/kernel/sysfs.c                        |    4 +-
 arch/sparc/kernel/time_64.c                      |    4 +-
 arch/x86/Kconfig                                 |    3 -
 arch/x86/include/asm/percpu.h                    |    9 +
 arch/x86/kernel/apic/apic.c                      |    2 +-
 arch/x86/kernel/apic/nmi.c                       |    8 +-
 arch/x86/kernel/apic/x2apic_cluster.c            |    2 +-
 arch/x86/kernel/cpu/common.c                     |    2 +-
 arch/x86/kernel/cpu/cpu_debug.c                  |    6 +-
 arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c       |    4 +-
 arch/x86/kernel/cpu/cpufreq/powernow-k8.c        |    2 +-
 arch/x86/kernel/cpu/cpufreq/speedstep-centrino.c |    4 +-
 arch/x86/kernel/cpu/intel_cacheinfo.c            |    6 +-
 arch/x86/kernel/cpu/mcheck/mce_amd_64.c          |    4 +-
 arch/x86/kernel/cpu/mcheck/mce_intel_64.c        |    2 +-
 arch/x86/kernel/cpu/mcheck/therm_throt.c         |    4 +-
 arch/x86/kernel/cpu/perf_counter.c               |   16 +-
 arch/x86/kernel/cpu/perfctr-watchdog.c           |    2 +-
 arch/x86/kernel/ds.c                             |    4 +-
 arch/x86/kernel/hpet.c                           |    2 +-
 arch/x86/kernel/irq_32.c                         |    8 +-
 arch/x86/kernel/kvm.c                            |    2 +-
 arch/x86/kernel/kvmclock.c                       |    2 +-
 arch/x86/kernel/paravirt.c                       |    2 +-
 arch/x86/kernel/process_64.c                     |    2 +-
 arch/x86/kernel/setup_percpu.c                   |  219 ++++++++++++++++------
 arch/x86/kernel/smpboot.c                        |    2 +-
 arch/x86/kernel/tlb_uv.c                         |    6 +-
 arch/x86/kernel/topology.c                       |    2 +-
 arch/x86/kernel/uv_time.c                        |    2 +-
 arch/x86/kernel/vmiclock_32.c                    |    2 +-
 arch/x86/kvm/svm.c                               |    2 +-
 arch/x86/kvm/vmx.c                               |    6 +-
 arch/x86/kvm/x86.c                               |    2 +-
 arch/x86/mm/kmemcheck/kmemcheck.c                |    2 +-
 arch/x86/mm/kmmio.c                              |    2 +-
 arch/x86/mm/mmio-mod.c                           |    4 +-
 arch/x86/mm/pageattr.c                           |   65 ++++---
 arch/x86/oprofile/nmi_int.c                      |    4 +-
 arch/x86/xen/enlighten.c                         |    4 +-
 arch/x86/xen/multicalls.c                        |    2 +-
 arch/x86/xen/smp.c                               |    8 +-
 arch/x86/xen/spinlock.c                          |    4 +-
 arch/x86/xen/time.c                              |   10 +-
 block/as-iosched.c                               |   10 +-
 block/blk-softirq.c                              |    2 +-
 block/cfq-iosched.c                              |   10 +-
 crypto/sha512_generic.c                          |    2 +-
 drivers/acpi/processor_core.c                    |    2 +-
 drivers/acpi/processor_thermal.c                 |    2 +-
 drivers/base/cpu.c                               |    2 +-
 drivers/char/random.c                            |    2 +-
 drivers/connector/cn_proc.c                      |    2 +-
 drivers/cpufreq/cpufreq.c                        |    8 +-
 drivers/cpufreq/cpufreq_conservative.c           |   12 +-
 drivers/cpufreq/cpufreq_ondemand.c               |   15 +-
 drivers/cpufreq/cpufreq_stats.c                  |    2 +-
 drivers/cpufreq/cpufreq_userspace.c              |   11 +-
 drivers/cpufreq/freq_table.c                     |    2 +-
 drivers/cpuidle/governors/ladder.c               |    2 +-
 drivers/cpuidle/governors/menu.c                 |    2 +-
 drivers/crypto/padlock-aes.c                     |    2 +-
 drivers/lguest/page_tables.c                     |    2 +-
 drivers/lguest/x86/core.c                        |    2 +-
 drivers/xen/events.c                             |   13 +-
 fs/buffer.c                                      |    4 +-
 fs/file.c                                        |    2 +-
 include/linux/percpu-defs.h                      |   10 +-
 include/linux/percpu.h                           |   12 +-
 init/main.c                                      |   24 ---
 kernel/kprobes.c                                 |    2 +-
 kernel/lockdep.c                                 |    2 +-
 kernel/module.c                                  |    6 +-
 kernel/perf_counter.c                            |    8 +-
 kernel/printk.c                                  |    2 +-
 kernel/profile.c                                 |    4 +-
 kernel/rcuclassic.c                              |    4 +-
 kernel/rcupdate.c                                |    2 +-
 kernel/rcupreempt.c                              |   10 +-
 kernel/rcutorture.c                              |    4 +-
 kernel/sched.c                                   |   30 ++--
 kernel/sched_clock.c                             |    2 +-
 kernel/sched_rt.c                                |    2 +-
 kernel/smp.c                                     |    6 +-
 kernel/softirq.c                                 |    6 +-
 kernel/softlockup.c                              |    6 +-
 kernel/taskstats.c                               |    4 +-
 kernel/time/tick-sched.c                         |    2 +-
 kernel/time/timer_stats.c                        |    2 +-
 kernel/timer.c                                   |    2 +-
 kernel/trace/ftrace.c                            |    2 +-
 kernel/trace/ring_buffer.c                       |    2 +-
 kernel/trace/trace.c                             |    6 +-
 kernel/trace/trace_events.c                      |    6 +-
 kernel/trace/trace_hw_branches.c                 |    4 +-
 kernel/trace/trace_irqsoff.c                     |    2 +-
 kernel/trace/trace_stack.c                       |    2 +-
 kernel/trace/trace_sysprof.c                     |    2 +-
 kernel/trace/trace_workqueue.c                   |    2 +-
 lib/radix-tree.c                                 |    2 +-
 lib/random32.c                                   |    2 +-
 mm/Makefile                                      |    2 +-
 mm/allocpercpu.c                                 |   28 +++
 mm/kmemleak-test.c                               |    6 +-
 mm/page-writeback.c                              |    5 +-
 mm/percpu.c                                      |   64 ++++++-
 mm/quicklist.c                                   |    2 +-
 mm/slab.c                                        |    4 +-
 mm/slub.c                                        |    6 +-
 mm/swap.c                                        |    4 +-
 mm/vmalloc.c                                     |    2 +-
 mm/vmstat.c                                      |    2 +-
 net/core/drop_monitor.c                          |    2 +-
 net/core/flow.c                                  |    6 +-
 net/core/sock.c                                  |    2 +-
 net/ipv4/route.c                                 |    2 +-
 net/ipv4/syncookies.c                            |    4 +-
 net/ipv6/syncookies.c                            |    4 +-
 net/rds/ib_stats.c                               |    2 +-
 net/rds/iw_stats.c                               |    2 +-
 net/rds/page.c                                   |    2 +-
 net/socket.c                                     |    2 +-
 170 files changed, 653 insertions(+), 553 deletions(-)

Jesper Nilsson (1):
      CRIS: Change DEFINE_PER_CPU of current_pgd to be non volatile.

Tejun Heo (16):
      percpu: fix too lazy vunmap cache flushing
      percpu: use dynamic percpu allocator as the default percpu allocator
      percpu: cleanup percpu array definitions
      use-percpu-aligned
      percpu: clean up percpu variable definitions
      percpu: enforce global definition
      alpha: kill unnecessary __used attribute in PER_CPU_ATTRIBUTES
      alpha: switch to dynamic percpu allocator
      s390: switch to dynamic percpu allocator
      x86: fix duplicate free in setup_pcpu_remap() failure path
      x86: rename remap percpu first chunk allocator to lpage
      x86: prepare setup_pcpu_lpage() for pageattr fix
      x86: reorganize cpa_process_alias()
      x86: fix pageattr handling for lpage percpu allocator and re-enable it
      x86: implement percpu_alloc kernel parameter
      x86: ensure percpu lpage doesn't consume too much vmalloc space


-- 
tejun

Re: [GIT PULL] percpu for 2.6.31

[Linus Torvalds]

On Thu, 18 Jun 2009, Tejun Heo wrote:
> 
> Please pull from percpu-for-linus git tree from:
> 
>     git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu.git for-linus

I'm very unhappy with this kind of crap.

Has it been tested AT ALL? Apparently not.

	arch/x86/kernel/cpu/mcheck/mce.c:98: error: multiple storage classes in declaration specifiers
	arch/x86/kernel/cpu/mcheck/mce.c:98: error: non-static declaration of ‘per_cpu__mces_seen’ follows static declaration
	arch/x86/kernel/cpu/mcheck/mce.c:98: note: previous declaration of ‘per_cpu__mces_seen’ was here
	.. and tons of other similar errors ..

and it was apparently done on purpose, for no good reason. The bug with 
static per-cpu variables is only for some broken architectures.

Even the _documentation_ uses "static DEFINE_PER_CPU(..)" for chissake!

To make matters worse, this whole series was clearly rebased (or applied 
from some other queue) just _minutes_ before sending it to me. No wonder 
it had zero testing:

 - commit:
	Date: Thu Jun 18 16:22:05 2009 +0900
 - email:
	Date: Thu, 18 Jun 2009 17:07:16 +0900

I'm not pulling it. Or rather, I pulled it, ended up doing other work, 
noticed the problems, and had to re-do my whole tree because I refuse to 
have sh*t like this in the kernel.

And I'm not going to pull trees that get rebased like this with basically 
no testing before sending it to me. There's a reason I don't like 
rebasing.

			Linus

Re: [GIT PULL] percpu for 2.6.31

[Andrew Morton]

On Thu, 18 Jun 2009 14:22:20 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, 18 Jun 2009, Tejun Heo wrote:
> > 
> > Please pull from percpu-for-linus git tree from:
> > 
> >     git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu.git for-linus
> 
> I'm very unhappy with this kind of crap.

AFACIT none of these patches have ever been in linux-next.  Half or
more of them turned up on the mailing list for the first time two days
ago and there's little evidence that anyone has even looked at them.

If this doesn't mean "you missed 2.6.31" then what does?



Yes, things like this can be messy and hard to develop and maintain
outside the merge window.  We understand this.  There are special
cases.  But when this happens, let's talk about it and see what we can
do!  Please let's not pretend that this is an ordinary old git merge
like all the others.

Re: [GIT PULL] percpu for 2.6.31

[Tejun Heo]

Hello, Andrew.

Andrew Morton wrote:
> On Thu, 18 Jun 2009 14:22:20 -0700 (PDT)
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
>> On Thu, 18 Jun 2009, Tejun Heo wrote:
>>> Please pull from percpu-for-linus git tree from:
>>>
>>>     git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu.git for-linus
>> I'm very unhappy with this kind of crap.
> 
> AFACIT none of these patches have ever been in linux-next.  Half or
> more of them turned up on the mailing list for the first time two days
> ago and there's little evidence that anyone has even looked at them.

Unfortunately, they grew out of their home so they didn't have proper
path to linux-next but I wasn't that careless.  The two patchsets went
through three and four revisions.

percpu-convert-most-archs-to-dynamic-percpu

    http://thread.gmane.org/gmane.linux.kernel.cross-arch/3818
    http://www.gossamer-threads.com/lists/linux/kernel/1083895
    http://thread.gmane.org/gmane.linux.kernel/839059

x86-percpu-fix-pageattr-handling

    http://thread.gmane.org/gmane.linux.kernel.cross-arch/3825
    http://thread.gmane.org/gmane.linux.kernel/844298
    http://article.gmane.org/gmane.linux.kernel/837157
    http://thread.gmane.org/gmane.linux.kernel/836771

> If this doesn't mean "you missed 2.6.31" then what does?
> 
> Yes, things like this can be messy and hard to develop and maintain
> outside the merge window.  We understand this.  There are special
> cases.  But when this happens, let's talk about it and see what we can
> do!  Please let's not pretend that this is an ordinary old git merge
> like all the others.

Sorry.  My fault.  It used to go through x86 and this was me realizing
that nobody was gonna take care of these patchsets and prepping trees
myself in a hurry.  Won't happen again.

Thanks.

-- 
tejun

Re: [GIT PULL] percpu for 2.6.31

[Ingo Molnar]

* Andrew Morton <akpm@linux-foundation.org> wrote:

> On Thu, 18 Jun 2009 14:22:20 -0700 (PDT)
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > On Thu, 18 Jun 2009, Tejun Heo wrote:
> > > 
> > > Please pull from percpu-for-linus git tree from:
> > > 
> > >     git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu.git for-linus
> > 
> > I'm very unhappy with this kind of crap.
> 
> AFACIT none of these patches have ever been in linux-next.  Half 
> or more of them turned up on the mailing list for the first time 
> two days ago and there's little evidence that anyone has even 
> looked at them.

Hm, i've seen many of them (for months literally) and you were 
definitely Cc:-ed to all of them. The new bits (which i think you 
are referring to) are not included in this series - only the old 
bits.

I even asked you about them a month ago, whether you'd want to pick 
Tejun's bits up into -mm because they are clearly generic VM patches 
and they seemed to be falling between the cracks for v2.6.31. I had 
two small bits of x86 relevant percpu patches which i'd gladly have 
bounced over to you.

Btw., it will be a lot of work for Tejun to go through another 3 
months with a patch-set of this magnitude:

  170 files changed, 653 insertions(+), 553 deletions(-)

and i suspect it will cause a fair amount of linux-next conflict 
resolution overhead as well. So Tejun, if you can get it tested 
please consider targeting it for this merge window still. I can
help out with some -tip testig if you want.

	Ingo

Re: [GIT PULL] percpu for 2.6.31

[Tejun Heo]

Hello, Linus.

Linus Torvalds wrote:
> 
> On Thu, 18 Jun 2009, Tejun Heo wrote:
>> Please pull from percpu-for-linus git tree from:
>>
>>     git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu.git for-linus
> 
> I'm very unhappy with this kind of crap.
> 
> Has it been tested AT ALL? Apparently not.
> 
> 	arch/x86/kernel/cpu/mcheck/mce.c:98: error: multiple storage classes in declaration specifiers
> 	arch/x86/kernel/cpu/mcheck/mce.c:98: error: non-static declaration of ‘per_cpu__mces_seen’ follows static declaration
> 	arch/x86/kernel/cpu/mcheck/mce.c:98: note: previous declaration of ‘per_cpu__mces_seen’ was here
> 	.. and tons of other similar errors ..

Oops, my apologies.  I had them as floating series and apparently used
different base commit when applying them.  I did grep run and full yes
build on the original quilt tree but didn't after quiltimport.  Sorry.

> and it was apparently done on purpose, for no good reason. The bug with 
> static per-cpu variables is only for some broken architectures.

Yes, for two of them s390 and alpha.  Another route was to tell the
compiler to generate external references were to use weak attribute
which also required globally unique name.  The first take of the
patchset used guard symbols to guarantee variable scope
(static/extern) and uniqueness while using weak attribute for the
actual percpu symbol.  It worked but was a bit too complex.  Consensus
(at least of the ones involved in the discussion) was limiting percpu
definitions to extern is an acceptable compromise.

> Even the _documentation_ uses "static DEFINE_PER_CPU(..)" for chissake!

Yeap, that was me going through grep output and thinking oh... I'll do
it later and then forget about it.  Will update now.

> To make matters worse, this whole series was clearly rebased (or applied 
> from some other queue) just _minutes_ before sending it to me. No wonder 
> it had zero testing:
> 
>  - commit:
> 	Date: Thu Jun 18 16:22:05 2009 +0900
>  - email:
> 	Date: Thu, 18 Jun 2009 17:07:16 +0900
> 
> I'm not pulling it. Or rather, I pulled it, ended up doing other work, 
> noticed the problems, and had to re-do my whole tree because I refuse to 
> have sh*t like this in the kernel.
> 
> And I'm not going to pull trees that get rebased like this with basically 
> no testing before sending it to me. There's a reason I don't like 
> rebasing.

Percpu patches used to run through Ingo's x86 tree (so reached
linux-next from there) but recent changes went out of scope for x86 so
the two patchsets posted here didn't have home.  They were posted well
before the merge window (IIRC the first postings were about two months
ago) and went through four and three revision cycles.

The tree was prepared in kind of hurry because I realized that no one
was gonna push it through a few days ago.  It's true that these
patches didn't see wider testing in linux-next or any other public
tree, so it seems these should wait for the next merge window.  I'll
maintain the percpu tree and push it through linux-next during this
devel cycle.

Sorry about the trouble.

Thanks.

-- 
tejun

Re: [GIT PULL] percpu for 2.6.31

[Tejun Heo]

Tejun Heo wrote:
> the two patchsets posted here didn't have home.  They were posted well
> before the merge window (IIRC the first postings were about two months
> ago) and went through four and three revision cycles.

Correction: They are four and five weeks old.  It somehow felt longer
to me.  :-)

-- 
tejun

Re: [GIT PULL] percpu for 2.6.31

[Tejun Heo]

Hello, again.

Tejun Heo wrote:
> Oops, my apologies.  I had them as floating series and apparently used
> different base commit when applying them.  I did grep run and full yes
> build on the original quilt tree but didn't after quiltimport.  Sorry.

I digged through git changelogs to find out where it went wrong.  I
did use the same base commit when quiltimporting but when I updated
the patches on top of mainline two days ago, I forgot to quilt add the
file and the mce change got committed to the base tree instead of
quilt patch.  After pulling the latest master into the quilt branch
yesterday, I updated the series for newcomers and everything worked
fine (as the base tree change got merged by git).  quiltimporting of
course lost the base tree change and thinking the output gotta be
identical I didn't test the final git tree.

Anyways, I'm dropping the for-linus branch from percpu tree, fixing it
up, adding patchsets scheduled for .32 release and will try to get it
merged into #linux-next.

Thanks.

-- 
tejun

Re: [GIT PULL] percpu for 2.6.31

[Ingo Molnar]

* Tejun Heo <tj@kernel.org> wrote:

> Hello, again.
> 
> Tejun Heo wrote:
> > Oops, my apologies.  I had them as floating series and apparently used
> > different base commit when applying them.  I did grep run and full yes
> > build on the original quilt tree but didn't after quiltimport.  Sorry.
> 
> I digged through git changelogs to find out where it went wrong.  
> I did use the same base commit when quiltimporting but when I 
> updated the patches on top of mainline two days ago, I forgot to 
> quilt add the file and the mce change got committed to the base 
> tree instead of quilt patch.  After pulling the latest master into 
> the quilt branch yesterday, I updated the series for newcomers and 
> everything worked fine (as the base tree change got merged by 
> git).  quiltimporting of course lost the base tree change and 
> thinking the output gotta be identical I didn't test the final git 
> tree.
> 
> Anyways, I'm dropping the for-linus branch from percpu tree, 
> fixing it up, adding patchsets scheduled for .32 release and will 
> try to get it merged into #linux-next.

Please create a -git based bit for the x86 side (as i asked you 
previously) - we can certainly get that upstream sooner after the 
necessary amount of testing.

Condolences for trying to improve a dozen SMP architectures at once, 
you've ended up with:

 - being forced to rebase all the time. (This will happen in the
   cycle to come too: just watch as the conflicts in linux-next
   mount up with the architecture trees. Your tree will become
   crappy quickly due to the combined noise.)

 - the 10x patch logistics end up killing your overall quality, let
   crap creep in and cause breakage even on x86.

You wasted 3 months of your life on that. Now you've learned not to 
do that ever again - i've been there, done that, got the T-shirt.

Just stick your new stuff behind an ARCH_HAS flag, add it to the 
architecture(s) you care about and forget about the rest - let the 
remaining arch maintainers pick things up in their own pace. You'll 
get 90% of the benefits to Linux with just 30% of the work.

( 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. )

	Ingo

Re: [GIT PULL] percpu for 2.6.31

[Linus Torvalds]

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.

			Linus

Re: [GIT PULL] percpu for 2.6.31

[Ingo Molnar]

* 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