* [RT] lockdep munching nr_list_entries like popcorn
@ 2017-02-16 6:03 Mike Galbraith
2017-02-16 8:37 ` Thomas Gleixner
0 siblings, 1 reply; 11+ messages in thread
From: Mike Galbraith @ 2017-02-16 6:03 UTC (permalink / raw)
To: RT; +Cc: LKML, Sebastian Andrzej Siewior, Thomas Gleixner
4.9.10-rt6-virgin on 72 core +SMT box.
Below is 1 line per minute, box idling along daintily nibbling, I fire
up a parallel kbuild loop at 40465, and box gobbles greedily.
I have entries bumped to 128k, and chain bits to 18 so box will get
booted and run for a while before lockdep says "I quit". With stock
settings, this box will barely get booted. Seems the bigger the box,
the sooner you're gonna run out. A NOPREEMPT kernel seems to nibble
entries too, but nowhere remotely near as greedily as RT.
<...>-100309 [064] d....13 2885.873312: add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40129
<...>-104320 [116] dN..211 2959.633630: add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40155
btrfs-transacti-1955 [043] d...111 3021.073949: add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40183
<...>-118865 [120] d....13 3086.146794: add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40209
systemd-logind-4763 [068] d....11 3146.953001: add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40239
<...>-123725 [032] dN..2.. 3215.735774: add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40285
<...>-33968 [031] d...1.. 3347.919001: add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40409
<...>-130886 [143] d....12 3412.586643: add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40465
<...>-138291 [037] d....11 3477.816405: add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 42825
<...>-67678 [137] d...112 3551.648282: add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 47899
ksoftirqd/45-421 [045] d....13 3617.926394: add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 48751
ihex2fw-24635 [035] d....11 3686.899690: add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 49345
<...>-76041 [047] d...111 3758.230009: add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 49757
stty-10772 [118] d...1.. 3825.626815: add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 50115
kworker/u289:4-13376 [075] d....12 3896.432428: add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 51189
<...>-92785 [047] d....12 3905.137578: add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 51287
With stacktrace on, buffer contains 1010 __lru_cache_add+0x4f...
(gdb) list *__lru_cache_add+0x4f
0xffffffff811dca9f is in __lru_cache_add (./include/linux/locallock.h:59).
54
55 static inline void __local_lock(struct local_irq_lock *lv)
56 {
57 if (lv->owner != current) {
58 spin_lock_local(&lv->lock);
59 LL_WARN(lv->owner);
60 LL_WARN(lv->nestcnt);
61 lv->owner = current;
62 }
63 lv->nestcnt++;
...which seems to be this.
0xffffffff811dca80 is in __lru_cache_add (mm/swap.c:397).
392 }
393 EXPORT_SYMBOL(mark_page_accessed);
394
395 static void __lru_cache_add(struct page *page)
396 {
397 struct pagevec *pvec = &get_locked_var(swapvec_lock, lru_add_pvec);
398
399 get_page(page);
400 if (!pagevec_add(pvec, page) || PageCompound(page))
401 __pagevec_lru_add(pvec);
swapvec_lock? Oodles of 'em? Nope.
-Mike
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [RT] lockdep munching nr_list_entries like popcorn 2017-02-16 6:03 [RT] lockdep munching nr_list_entries like popcorn Mike Galbraith @ 2017-02-16 8:37 ` Thomas Gleixner 2017-02-16 8:50 ` Mike Galbraith 0 siblings, 1 reply; 11+ messages in thread From: Thomas Gleixner @ 2017-02-16 8:37 UTC (permalink / raw) To: Mike Galbraith; +Cc: RT, LKML, Sebastian Andrzej Siewior On Thu, 16 Feb 2017, Mike Galbraith wrote: > 4.9.10-rt6-virgin on 72 core +SMT box. > > Below is 1 line per minute, box idling along daintily nibbling, I fire > up a parallel kbuild loop at 40465, and box gobbles greedily. > > I have entries bumped to 128k, and chain bits to 18 so box will get > booted and run for a while before lockdep says "I quit". With stock > settings, this box will barely get booted. Seems the bigger the box, > the sooner you're gonna run out. A NOPREEMPT kernel seems to nibble > entries too, but nowhere remotely near as greedily as RT. Right. RT adds a bunch of locks through the local lock mechanism. > <...>-100309 [064] d....13 2885.873312: add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 40129 > <...>-92785 [047] d....12 3905.137578: add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 51287 That's odd. > With stacktrace on, buffer contains 1010 __lru_cache_add+0x4f... > > (gdb) list *__lru_cache_add+0x4f > 0xffffffff811dca9f is in __lru_cache_add (./include/linux/locallock.h:59). > 54 > 55 static inline void __local_lock(struct local_irq_lock *lv) > 56 { > 57 if (lv->owner != current) { > 58 spin_lock_local(&lv->lock); > 59 LL_WARN(lv->owner); > 60 LL_WARN(lv->nestcnt); > 61 lv->owner = current; > 62 } > 63 lv->nestcnt++; > > ...which seems to be this. > > 0xffffffff811dca80 is in __lru_cache_add (mm/swap.c:397). > 392 } > 393 EXPORT_SYMBOL(mark_page_accessed); > 394 > 395 static void __lru_cache_add(struct page *page) > 396 { > 397 struct pagevec *pvec = &get_locked_var(swapvec_lock, lru_add_pvec); > 398 > 399 get_page(page); > 400 if (!pagevec_add(pvec, page) || PageCompound(page)) > 401 __pagevec_lru_add(pvec); > > swapvec_lock? Oodles of 'em? Nope. Well, it's a per cpu lock and the lru_cache_add() variants might be called from a gazillion of different call chains, but yes, it does not make a lot of sense. We'll have a look. Thanks, tglx ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RT] lockdep munching nr_list_entries like popcorn 2017-02-16 8:37 ` Thomas Gleixner @ 2017-02-16 8:50 ` Mike Galbraith 2017-02-16 9:01 ` Thomas Gleixner 0 siblings, 1 reply; 11+ messages in thread From: Mike Galbraith @ 2017-02-16 8:50 UTC (permalink / raw) To: Thomas Gleixner; +Cc: RT, LKML, Sebastian Andrzej Siewior On Thu, 2017-02-16 at 09:37 +0100, Thomas Gleixner wrote: > On Thu, 16 Feb 2017, Mike Galbraith wrote: > ... > > swapvec_lock? Oodles of 'em? Nope. > > Well, it's a per cpu lock and the lru_cache_add() variants might be called > from a gazillion of different call chains, but yes, it does not make a lot > of sense. We'll have a look. Adding explicit local_irq_lock_init() makes things heaps better, so presumably we need better lockdep-foo in DEFINE_LOCAL_IRQ_LOCK(). -Mike ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RT] lockdep munching nr_list_entries like popcorn 2017-02-16 8:50 ` Mike Galbraith @ 2017-02-16 9:01 ` Thomas Gleixner 2017-02-16 9:27 ` Mike Galbraith 2017-02-16 11:06 ` Peter Zijlstra 0 siblings, 2 replies; 11+ messages in thread From: Thomas Gleixner @ 2017-02-16 9:01 UTC (permalink / raw) To: Mike Galbraith; +Cc: RT, LKML, Sebastian Andrzej Siewior On Thu, 16 Feb 2017, Mike Galbraith wrote: > On Thu, 2017-02-16 at 09:37 +0100, Thomas Gleixner wrote: > > On Thu, 16 Feb 2017, Mike Galbraith wrote: > > > ... > > > swapvec_lock? Oodles of 'em? Nope. > > > > Well, it's a per cpu lock and the lru_cache_add() variants might be called > > from a gazillion of different call chains, but yes, it does not make a lot > > of sense. We'll have a look. > > Adding explicit local_irq_lock_init() makes things heaps better, so > presumably we need better lockdep-foo in DEFINE_LOCAL_IRQ_LOCK(). Bah. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RT] lockdep munching nr_list_entries like popcorn 2017-02-16 9:01 ` Thomas Gleixner @ 2017-02-16 9:27 ` Mike Galbraith 2017-02-16 11:06 ` Peter Zijlstra 1 sibling, 0 replies; 11+ messages in thread From: Mike Galbraith @ 2017-02-16 9:27 UTC (permalink / raw) To: Thomas Gleixner; +Cc: RT, LKML, Sebastian Andrzej Siewior On Thu, 2017-02-16 at 10:01 +0100, Thomas Gleixner wrote: > On Thu, 16 Feb 2017, Mike Galbraith wrote: > > > On Thu, 2017-02-16 at 09:37 +0100, Thomas Gleixner wrote: > > > On Thu, 16 Feb 2017, Mike Galbraith wrote: > > > > > ... > > > > swapvec_lock? Oodles of 'em? Nope. > > > > > > Well, it's a per cpu lock and the lru_cache_add() variants might be called > > > from a gazillion of different call chains, but yes, it does not make a lot > > > of sense. We'll have a look. > > > > Adding explicit local_irq_lock_init() makes things heaps better, so > > presumably we need better lockdep-foo in DEFINE_LOCAL_IRQ_LOCK(). > > Bah. Hm, "bah" sounds kinda like it might be a synonym for -EDUMMY :) Fair enough, I know spit about about lockdep, so that's likely the case, but the below has me down to ~17k (and climbing, but not as fast). berio:/sys/kernel/debug/tracing/:[0]# grep -A 1 'stack trace' trace|grep '=>'|sort|uniq => ___slab_alloc+0x171/0x5c0 => __percpu_counter_add+0x56/0xd0 => __schedule+0xb0/0x7b0 => __slab_free+0xd8/0x200 => cgroup_idr_alloc.constprop.39+0x37/0x80 => hrtimer_start_range_ns+0xe6/0x400 => idr_preload+0x6c/0x300 => jbd2_journal_extend+0x4c/0x310 [jbd2] => lock_hrtimer_base.isra.28+0x29/0x50 => rcu_note_context_switch+0x2b8/0x5c0 => rcu_report_unblock_qs_rnp+0x6e/0xa0 => rt_mutex_slowunlock+0x25/0xc0 => rt_spin_lock_slowlock+0x52/0x330 => rt_spin_lock_slowlock+0x94/0x330 => rt_spin_lock_slowunlock+0x3c/0xc0 => swake_up+0x21/0x40 => task_blocks_on_rt_mutex+0x42/0x1e0 => try_to_wake_up+0x2d/0x920 berio:/sys/kernel/debug/tracing/:[0]# grep nr_list_entries: trace|tail -1 irq/66-eth2-TxR-3670 [115] d....14 1542.321173: add_lock_to_list.isra.24.constprop.42+0x20/0x100: nr_list_entries: 17839 Got rid of the really pesky growth anyway. --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -5522,6 +5522,7 @@ static int __init init_workqueues(void) pwq_cache = KMEM_CACHE(pool_workqueue, SLAB_PANIC); + local_irq_lock_init(pendingb_lock); wq_numa_init(); /* initialize CPU pools */ --- a/lib/radix-tree.c +++ b/lib/radix-tree.c @@ -1677,5 +1677,6 @@ void __init radix_tree_init(void) SLAB_PANIC | SLAB_RECLAIM_ACCOUNT, radix_tree_node_ctor); radix_tree_init_maxnodes(); + local_irq_lock_init(radix_tree_preloads_lock); hotcpu_notifier(radix_tree_callback, 0); } --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -5786,6 +5786,7 @@ static int __init mem_cgroup_init(void) int cpu, node; hotcpu_notifier(memcg_cpu_hotplug_callback, 0); + local_irq_lock_init(event_lock); for_each_possible_cpu(cpu) INIT_WORK(&per_cpu_ptr(&memcg_stock, cpu)->work, --- a/mm/swap.c +++ b/mm/swap.c @@ -681,6 +681,14 @@ static inline void remote_lru_add_drain( local_unlock_on(swapvec_lock, cpu); } +static int __init lru_init(void) +{ + local_irq_lock_init(swapvec_lock); + local_irq_lock_init(rotate_lock); + return 0; +} +early_initcall(lru_init); + #else /* --- a/net/netfilter/core.c +++ b/net/netfilter/core.c @@ -525,6 +525,7 @@ int __init netfilter_init(void) { int ret; + local_irq_lock_init(xt_write_lock); ret = register_pernet_subsys(&netfilter_net_ops); if (ret < 0) goto err; ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RT] lockdep munching nr_list_entries like popcorn 2017-02-16 9:01 ` Thomas Gleixner 2017-02-16 9:27 ` Mike Galbraith @ 2017-02-16 11:06 ` Peter Zijlstra 2017-02-16 14:42 ` Mike Galbraith 1 sibling, 1 reply; 11+ messages in thread From: Peter Zijlstra @ 2017-02-16 11:06 UTC (permalink / raw) To: Thomas Gleixner; +Cc: Mike Galbraith, RT, LKML, Sebastian Andrzej Siewior On Thu, Feb 16, 2017 at 10:01:18AM +0100, Thomas Gleixner wrote: > On Thu, 16 Feb 2017, Mike Galbraith wrote: > > > On Thu, 2017-02-16 at 09:37 +0100, Thomas Gleixner wrote: > > > On Thu, 16 Feb 2017, Mike Galbraith wrote: > > > > > ... > > > > swapvec_lock? Oodles of 'em? Nope. > > > > > > Well, it's a per cpu lock and the lru_cache_add() variants might be called > > > from a gazillion of different call chains, but yes, it does not make a lot > > > of sense. We'll have a look. > > > > Adding explicit local_irq_lock_init() makes things heaps better, so > > presumably we need better lockdep-foo in DEFINE_LOCAL_IRQ_LOCK(). > > Bah. #ifdef CONFIG_DEBUG_LOCK_ALLOC #define PER_CPU_DEP_MAP_INIT(lockname) \ .dep_map = { \ .key = ({ static struct lock_class_key __key; &__key }), \ .name = #lockname, \ } #else #define PER_CPU_DEP_MAP_INIT(lockname) #endif #define DEFINE_LOCAL_IRQ_LOCK(lvar) \ DEFINE_PER_CPU(struct local_irq_lock, lvar) = { \ .lock = { .rlock = { \ .raw_lock = __ARCH_SPIN_LOCK_UNLOCKED, \ SPIN_DEBUG_INIT(lvar) \ PER_CPU_DEP_MAP_INIT(lvar) \ } } \ } That's fairly horrible for poking inside all the internals, but it might just work ;-) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RT] lockdep munching nr_list_entries like popcorn 2017-02-16 11:06 ` Peter Zijlstra @ 2017-02-16 14:42 ` Mike Galbraith 2017-02-16 14:53 ` Sebastian Andrzej Siewior 0 siblings, 1 reply; 11+ messages in thread From: Mike Galbraith @ 2017-02-16 14:42 UTC (permalink / raw) To: Peter Zijlstra, Thomas Gleixner; +Cc: RT, LKML, Sebastian Andrzej Siewior On Thu, 2017-02-16 at 12:06 +0100, Peter Zijlstra wrote: > On Thu, Feb 16, 2017 at 10:01:18AM +0100, Thomas Gleixner wrote: > > On Thu, 16 Feb 2017, Mike Galbraith wrote: > > > > > On Thu, 2017-02-16 at 09:37 +0100, Thomas Gleixner wrote: > > > > On Thu, 16 Feb 2017, Mike Galbraith wrote: > > > > > > > ... > > > > > swapvec_lock? Oodles of 'em? Nope. > > > > > > > > Well, it's a per cpu lock and the lru_cache_add() variants might be called > > > > from a gazillion of different call chains, but yes, it does not make a lot > > > > of sense. We'll have a look. > > > > > > Adding explicit local_irq_lock_init() makes things heaps better, so > > > presumably we need better lockdep-foo in DEFINE_LOCAL_IRQ_LOCK(). > > > > Bah. > > > #ifdef CONFIG_DEBUG_LOCK_ALLOC > #define PER_CPU_DEP_MAP_INIT(lockname) \ > .dep_map = { \ > .key = ({ static struct lock_class_key __key; &__key }), \ > .name = #lockname, \ > } > #else > #define PER_CPU_DEP_MAP_INIT(lockname) > #endif > > #define DEFINE_LOCAL_IRQ_LOCK(lvar) \ > DEFINE_PER_CPU(struct local_irq_lock, lvar) = { \ > .lock = { .rlock = { \ > .raw_lock = __ARCH_SPIN_LOCK_UNLOCKED, \ > SPIN_DEBUG_INIT(lvar) \ > PER_CPU_DEP_MAP_INIT(lvar) \ > } } \ > } > > That's fairly horrible for poking inside all the internals, but it might > just work ;- Weeell, I'm trying to cobble something kinda like that together using __RT_SPIN_INITIALIZER() instead, but seems mean ole Mr. Compiler NAKs the PER_CPU_DEP_MAP_INIT() thingy. CC mm/swap.o mm/swap.c:54:689: error: braced-group within expression allowed only inside a function -Mike ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RT] lockdep munching nr_list_entries like popcorn 2017-02-16 14:42 ` Mike Galbraith @ 2017-02-16 14:53 ` Sebastian Andrzej Siewior 2017-02-16 18:06 ` Mike Galbraith 0 siblings, 1 reply; 11+ messages in thread From: Sebastian Andrzej Siewior @ 2017-02-16 14:53 UTC (permalink / raw) To: Mike Galbraith; +Cc: Peter Zijlstra, Thomas Gleixner, RT, LKML On 2017-02-16 15:42:59 [+0100], Mike Galbraith wrote: > > Weeell, I'm trying to cobble something kinda like that together using > __RT_SPIN_INITIALIZER() instead, but seems mean ole Mr. Compiler NAKs > the PER_CPU_DEP_MAP_INIT() thingy. > > CC mm/swap.o > mm/swap.c:54:689: error: braced-group within expression allowed only > inside a function so this is what I have now. I need to get the `static' symbol working again and PER_CPU_DEP_MAP_INIT but aside from that it seems to do its job. diff --git a/include/linux/locallock.h b/include/linux/locallock.h index 845c77f1a5ca..36201b37012d 100644 --- a/include/linux/locallock.h +++ b/include/linux/locallock.h @@ -22,9 +22,27 @@ struct local_irq_lock { unsigned long flags; }; +#ifdef CONFIG_DEBUG_LOCK_ALLOC +#define PER_CPU_DEP_MAP_INIT(lockname) \ + .dep_map = { \ + .key = ({ static struct lock_class_key __key; &__key }),\ + .name = #lockname, \ + } +#else +#define PER_CPU_DEP_MAP_INIT(lockname) +#endif + #define DEFINE_LOCAL_IRQ_LOCK(lvar) \ + struct lock_class_key lvar##__key; \ DEFINE_PER_CPU(struct local_irq_lock, lvar) = { \ - .lock = __SPIN_LOCK_UNLOCKED((lvar).lock) } + .lock = { \ + .lock = __RT_SPIN_INITIALIZER(lvar.lock), \ + .dep_map = { \ + .key = &lvar##__key, \ + .name = #lvar, \ + } \ + } \ + } #define DECLARE_LOCAL_IRQ_LOCK(lvar) \ DECLARE_PER_CPU(struct local_irq_lock, lvar) > -Mike Sebastian ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [RT] lockdep munching nr_list_entries like popcorn 2017-02-16 14:53 ` Sebastian Andrzej Siewior @ 2017-02-16 18:06 ` Mike Galbraith 2017-02-16 18:16 ` Mike Galbraith 2017-02-17 20:55 ` Mike Galbraith 0 siblings, 2 replies; 11+ messages in thread From: Mike Galbraith @ 2017-02-16 18:06 UTC (permalink / raw) To: Sebastian Andrzej Siewior; +Cc: Peter Zijlstra, Thomas Gleixner, RT, LKML On Thu, 2017-02-16 at 15:53 +0100, Sebastian Andrzej Siewior wrote: > On 2017-02-16 15:42:59 [+0100], Mike Galbraith wrote: > > > > Weeell, I'm trying to cobble something kinda like that together using > > __RT_SPIN_INITIALIZER() instead, but seems mean ole Mr. Compiler NAKs > > the PER_CPU_DEP_MAP_INIT() thingy. > > > > CC mm/swap.o > > mm/swap.c:54:689: error: braced-group within expression allowed only > > inside a function > > so this is what I have now. I need to get the `static' symbol working > again and PER_CPU_DEP_MAP_INIT but aside from that it seems to do its > job. ... Yeah, works, I should be able to do an ltp run with stock lockdep settings without it taking it's toys and going home in a snit. berio:/sys/kernel/debug/tracing/:[0]# !while while sleep 60; do tail -1 trace; done <...>-10315 [064] d...1.. 226.953935: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 14223 w-13148 [120] d...111 287.414978: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 14465 w-16492 [089] d...111 347.128742: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 14653 (starts kbuild loop) btrfs-transacti-1964 [016] d...1.. 411.101549: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 17011 <...>-100268 [127] d...112 472.271769: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 18153 w-18864 [011] d...1.. 534.386443: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 18543 <...>-50390 [035] dN..2.. 597.794164: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 18765 <...>-80098 [127] d...111 659.912145: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 18977 checkproc-11123 [017] d...1.. 721.483463: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 19247 <idle>-0 [055] d..h5.. 782.685953: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 19383 <...>-93632 [055] d...111 835.527817: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 19441 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RT] lockdep munching nr_list_entries like popcorn 2017-02-16 18:06 ` Mike Galbraith @ 2017-02-16 18:16 ` Mike Galbraith 2017-02-17 20:55 ` Mike Galbraith 1 sibling, 0 replies; 11+ messages in thread From: Mike Galbraith @ 2017-02-16 18:16 UTC (permalink / raw) To: Sebastian Andrzej Siewior; +Cc: Peter Zijlstra, Thomas Gleixner, RT, LKML BTW, this ain't gone. I'll take a peek. It doesn't happen in my tree, seems likely to be because whether running sirqs fully threaded or not, I don't let one any thread handle what another exists to handle. [ 638.107293] NOHZ: local_softirq_pending 80 [ 939.729684] NOHZ: local_softirq_pending 80 [ 945.600869] NOHZ: local_softirq_pending 80 [ 1387.101178] NOHZ: local_softirq_pending 80 [ 1387.101343] NOHZ: local_softirq_pending 80 [ 1387.101549] NOHZ: local_softirq_pending 80 [ 1413.313212] NOHZ: local_softirq_pending 80 [ 1413.313305] NOHZ: local_softirq_pending 80 [ 1413.313347] NOHZ: local_softirq_pending 80 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RT] lockdep munching nr_list_entries like popcorn 2017-02-16 18:06 ` Mike Galbraith 2017-02-16 18:16 ` Mike Galbraith @ 2017-02-17 20:55 ` Mike Galbraith 1 sibling, 0 replies; 11+ messages in thread From: Mike Galbraith @ 2017-02-17 20:55 UTC (permalink / raw) To: Sebastian Andrzej Siewior; +Cc: Peter Zijlstra, Thomas Gleixner, RT, LKML On Thu, 2017-02-16 at 19:06 +0100, Mike Galbraith wrote: > On Thu, 2017-02-16 at 15:53 +0100, Sebastian Andrzej Siewior wrote: > > On 2017-02-16 15:42:59 [+0100], Mike Galbraith wrote: > > > > > > Weeell, I'm trying to cobble something kinda like that together using > > > __RT_SPIN_INITIALIZER() instead, but seems mean ole Mr. Compiler NAKs > > > the PER_CPU_DEP_MAP_INIT() thingy. > > > > > > CC mm/swap.o > > > mm/swap.c:54:689: error: braced-group within expression allowed only > > > inside a function > > > > so this is what I have now. I need to get the `static' symbol working > > again and PER_CPU_DEP_MAP_INIT but aside from that it seems to do its > > job. > > ... > > Yeah, works, I should be able to do an ltp run with stock lockdep > settings without it taking it's toys and going home in a snit. > > berio:/sys/kernel/debug/tracing/:[0]# !while > while sleep 60; do tail -1 trace; done > <...>-10315 [064] d...1.. 226.953935: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 14223 > w-13148 [120] d...111 287.414978: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 14465 > w-16492 [089] d...111 347.128742: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 14653 > (starts kbuild loop) > btrfs-transacti-1964 [016] d...1.. 411.101549: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 17011 > <...>-100268 [127] d...112 472.271769: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 18153 > w-18864 [011] d...1.. 534.386443: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 18543 > <...>-50390 [035] dN..2.. 597.794164: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 18765 > <...>-80098 [127] d...111 659.912145: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 18977 > checkproc-11123 [017] d...1.. 721.483463: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 19247 > -0 [055] d..h5.. 782.685953: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 19383 > <...>-93632 [055] d...111 835.527817: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 19441 And now Thomas's patch. Spiffiness. Now to start ltp. berio:/sys/kernel/debug/tracing/:[0]# !while while sleep 60; do tail -1 trace; done <...>-12462 [105] d...1.. 211.489528: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 12847 btrfs-transacti-3136 [002] d...211 272.672777: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 12947 irq/155-eth2-Tx-4495 [096] dN..213 332.035236: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 13001 (starts kbuild loop) <...>-44245 [087] d...114 396.892748: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 13917 <...>-105411 [067] dN..211 457.708259: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 14367 w-21800 [113] dN..2.. 519.231735: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 14449 modpost-31558 [020] d....11 576.065855: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 14601 kworker/dying-11860 [133] d...112 637.170497: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 14679 <...>-118853 [055] d....11 703.884755: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 14759 <...>-52143 [090] d...1.. 767.624735: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 14813 <...>-71788 [126] d...1.. 829.160330: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 14857 kworker/u289:5-2991 [002] d...1.. 892.402939: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 14883 sh-15106 [008] d...211 953.172196: add_lock_to_list.isra.24.constprop.42: nr_list_entries: 14937 > ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2017-02-17 20:56 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-02-16 6:03 [RT] lockdep munching nr_list_entries like popcorn Mike Galbraith 2017-02-16 8:37 ` Thomas Gleixner 2017-02-16 8:50 ` Mike Galbraith 2017-02-16 9:01 ` Thomas Gleixner 2017-02-16 9:27 ` Mike Galbraith 2017-02-16 11:06 ` Peter Zijlstra 2017-02-16 14:42 ` Mike Galbraith 2017-02-16 14:53 ` Sebastian Andrzej Siewior 2017-02-16 18:06 ` Mike Galbraith 2017-02-16 18:16 ` Mike Galbraith 2017-02-17 20:55 ` Mike Galbraith
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).