mm: preemptibility -v2
in [Kernel]
|
Prev: Staging: comedi: fix brace, print(k), indent and over 80 character coding style issues in adq12b.c
Next: powerpc: Add rcu_read_lock() to gup_fast() implementation
From: David Miller on 8 Apr 2010 16:40 From: Peter Zijlstra <a.p.zijlstra(a)chello.nl> Date: Thu, 08 Apr 2010 21:17:37 +0200 > This patch-set seems to build and boot on my x86_64 machines and even builds a > kernel. I've also attempted powerpc and sparc, which I've compile tested with > their respective defconfigs, remaining are (afaikt the rest uses the generic > tlb bits): Did a build and test boot of this on my 128-cpu Niagara2 box, seems to work basically fine. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 8 Apr 2010 16:40 On Thu, 2010-04-08 at 13:29 -0700, David Miller wrote: > From: Peter Zijlstra <a.p.zijlstra(a)chello.nl> > Date: Thu, 08 Apr 2010 21:17:37 +0200 > > > This patch-set seems to build and boot on my x86_64 machines and even builds a > > kernel. I've also attempted powerpc and sparc, which I've compile tested with > > their respective defconfigs, remaining are (afaikt the rest uses the generic > > tlb bits): > > Did a build and test boot of this on my 128-cpu Niagara2 box, seems to > work basically fine. Wheee, thanks Dave! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Miller on 8 Apr 2010 21:10 From: David Miller <davem(a)davemloft.net> Date: Thu, 08 Apr 2010 13:29:35 -0700 (PDT) > From: Peter Zijlstra <a.p.zijlstra(a)chello.nl> > Date: Thu, 08 Apr 2010 21:17:37 +0200 > >> This patch-set seems to build and boot on my x86_64 machines and even builds a >> kernel. I've also attempted powerpc and sparc, which I've compile tested with >> their respective defconfigs, remaining are (afaikt the rest uses the generic >> tlb bits): > > Did a build and test boot of this on my 128-cpu Niagara2 box, seems to > work basically fine. Here comes a set of 4 patches which build on top of your work by: 1) Killing quicklists on sparc64 2) Using the generic RCU page table liberation code on sparc64 3) Implement pte_special() et al. on sparc64 4) Implement get_user_pages_fast() on sparc64 Please add them to your patch set. If you change the RCU generic code enabler CPP define to be controlled via Kconfig (as we discussed on IRC) it should be easy to propagate that change into patch #2 here. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Nick Piggin on 9 Apr 2010 00:20 On Thu, Apr 08, 2010 at 09:17:37PM +0200, Peter Zijlstra wrote: > Hi, > > This (still incomplete) patch-set makes part of the mm a lot more preemptible. > It converts i_mmap_lock and anon_vma->lock to mutexes. On the way there it > also makes mmu_gather preemptible. > > The main motivation was making mm_take_all_locks() preemptible, since it > appears people are nesting hundreds of spinlocks there. > > The side-effects are that we can finally make mmu_gather preemptible, something > which lots of people have wanted to do for a long time. What's the straight-line performance impact of all this? And how about concurrency, I wonder. mutexes of course are double the atomics, and you've added a refcount which is two more again for those paths using it. Page faults are very important. We unfortunately have some databases doing a significant amount of mmap/munmap activity too. I'd like to see microbenchmark numbers for each of those (both anon and file backed for page faults). kbuild does quite a few pages faults, that would be an easy thing to test. Not sure what reasonable kinds of cases exercise parallelism. > What kind of performance tests would people have me run on this to satisfy > their need for numbers? I've done a kernel build on x86_64 and if anything that > was slightly faster with these patches, but it was well within the noise > levels so it might be heat noise I'm looking at ;-) Is it because you're reducing the number of TLB flushes, or what (kbuild isn't multi threaded so on x86 TLB flushes should be really fast anyway). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 9 Apr 2010 04:40
On Fri, 2010-04-09 at 14:14 +1000, Nick Piggin wrote: > On Thu, Apr 08, 2010 at 09:17:37PM +0200, Peter Zijlstra wrote: > > Hi, > > > > This (still incomplete) patch-set makes part of the mm a lot more preemptible. > > It converts i_mmap_lock and anon_vma->lock to mutexes. On the way there it > > also makes mmu_gather preemptible. > > > > The main motivation was making mm_take_all_locks() preemptible, since it > > appears people are nesting hundreds of spinlocks there. > > > > The side-effects are that we can finally make mmu_gather preemptible, something > > which lots of people have wanted to do for a long time. > > What's the straight-line performance impact of all this? And how about > concurrency, I wonder. mutexes of course are double the atomics, and > you've added a refcount which is two more again for those paths using > it. > > Page faults are very important. We unfortunately have some databases > doing a significant amount of mmap/munmap activity too. You think this would affect the mmap/munmap times in any significant way? It seems to me those are relatively heavy ops to begin with. > I'd like to > see microbenchmark numbers for each of those (both anon and file backed > for page faults). OK, I'll dig out that fault test used in the whole mmap_sem/rwsem thread a while back and modify it to also do file backed faults. > kbuild does quite a few pages faults, that would be an easy thing to > test. Not sure what reasonable kinds of cases exercise parallelism. > > > > What kind of performance tests would people have me run on this to satisfy > > their need for numbers? I've done a kernel build on x86_64 and if anything that > > was slightly faster with these patches, but it was well within the noise > > levels so it might be heat noise I'm looking at ;-) > > Is it because you're reducing the number of TLB flushes, or what > (kbuild isn't multi threaded so on x86 TLB flushes should be really > fast anyway). I'll try and get some perf stat runs to get some insight into this. But the numbers were: time make O=defconfig -j48 bzImage (5x, cache hot) without: avg: 39.2018s +- 0.3407 with: avg: 38.9886s +- 0.1814 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |