From: Peter Zijlstra <peterz@infradead.org> To: Nick Piggin <nickpiggin@yahoo.com.au> Cc: David Miller <davem@davemloft.net>, jarkao2@gmail.com, Larry.Finger@lwfinger.net, kaber@trash.net, torvalds@linux-foundation.org, akpm@linux-foundation.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org, mingo@redhat.com, paulmck@linux.vnet.ibm.com, Thomas Gleixner <tglx@linutronix.de> Subject: Re: Kernel WARNING: at net/core/dev.c:1330 __netif_schedule+0x2c/0x98() Date: Thu, 24 Jul 2008 12:59:46 +0200 [thread overview] Message-ID: <1216897186.7257.279.camel@twins> (raw) In-Reply-To: <200807242038.36693.nickpiggin@yahoo.com.au> On Thu, 2008-07-24 at 20:38 +1000, Nick Piggin wrote: > On Thursday 24 July 2008 20:08, Peter Zijlstra wrote: > > On Thu, 2008-07-24 at 02:32 -0700, David Miller wrote: > > > From: Peter Zijlstra <peterz@infradead.org> > > > Date: Thu, 24 Jul 2008 11:27:05 +0200 > > > > > > > Well, not only lockdep, taking a very large number of locks is > > > > expensive as well. > > > > > > Right now it would be on the order of 16 or 32 for > > > real hardware. > > > > > > Much less than the scheduler currently takes on some > > > of my systems, so currently you are the pot calling the > > > kettle black. :-) > > > > One nit, and then I'll let this issue rest :-) > > > > The scheduler has a long lock dependancy chain (nr_cpu_ids rq locks), > > but it never takes all of them at the same time. Any one code path will > > at most hold two rq locks. > > Aside from lockdep, is there a particular problem with taking 64k locks > at once? (in a very slow path, of course) I don't think it causes a > problem with preempt_count, does it cause issues with -rt kernel? PI-chains might explode I guess, Thomas? Besides that, I just have this voice in my head telling me that minimizing the number of locks held is a good thing. > Hey, something kind of cool (and OT) I've just thought of that we can > do with ticket locks is to take tickets for 2 (or 64K) nested locks, > and then wait for them both (all), so the cost is N*lock + longest spin, > rather than N*lock + N*avg spin. > > That would mean even at the worst case of a huge amount of contention > on all 64K locks, it should only take a couple of ms to take all of > them (assuming max spin time isn't ridiculous). > > Probably not the kind of feature we want to expose widely, but for > really special things like the scheduler, it might be a neat hack to > save a few cycles ;) Traditional implementations would just have > #define spin_lock_async spin_lock > #define spin_lock_async_wait do {} while (0) > > Sorry it's offtopic, but if I didn't post it, I'd forget to. Might be > a fun quick hack for someone. It might just be worth it for double_rq_lock() - if you can sort out the deadlock potential Miklos just raised ;-)
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> To: Nick Piggin <nickpiggin-/E1597aS9LT0CCvOHzKKcA@public.gmane.org> Cc: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>, jarkao2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org, kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org, torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org, Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org> Subject: Re: Kernel WARNING: at net/core/dev.c:1330 __netif_schedule+0x2c/0x98() Date: Thu, 24 Jul 2008 12:59:46 +0200 [thread overview] Message-ID: <1216897186.7257.279.camel@twins> (raw) In-Reply-To: <200807242038.36693.nickpiggin-/E1597aS9LT0CCvOHzKKcA@public.gmane.org> On Thu, 2008-07-24 at 20:38 +1000, Nick Piggin wrote: > On Thursday 24 July 2008 20:08, Peter Zijlstra wrote: > > On Thu, 2008-07-24 at 02:32 -0700, David Miller wrote: > > > From: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> > > > Date: Thu, 24 Jul 2008 11:27:05 +0200 > > > > > > > Well, not only lockdep, taking a very large number of locks is > > > > expensive as well. > > > > > > Right now it would be on the order of 16 or 32 for > > > real hardware. > > > > > > Much less than the scheduler currently takes on some > > > of my systems, so currently you are the pot calling the > > > kettle black. :-) > > > > One nit, and then I'll let this issue rest :-) > > > > The scheduler has a long lock dependancy chain (nr_cpu_ids rq locks), > > but it never takes all of them at the same time. Any one code path will > > at most hold two rq locks. > > Aside from lockdep, is there a particular problem with taking 64k locks > at once? (in a very slow path, of course) I don't think it causes a > problem with preempt_count, does it cause issues with -rt kernel? PI-chains might explode I guess, Thomas? Besides that, I just have this voice in my head telling me that minimizing the number of locks held is a good thing. > Hey, something kind of cool (and OT) I've just thought of that we can > do with ticket locks is to take tickets for 2 (or 64K) nested locks, > and then wait for them both (all), so the cost is N*lock + longest spin, > rather than N*lock + N*avg spin. > > That would mean even at the worst case of a huge amount of contention > on all 64K locks, it should only take a couple of ms to take all of > them (assuming max spin time isn't ridiculous). > > Probably not the kind of feature we want to expose widely, but for > really special things like the scheduler, it might be a neat hack to > save a few cycles ;) Traditional implementations would just have > #define spin_lock_async spin_lock > #define spin_lock_async_wait do {} while (0) > > Sorry it's offtopic, but if I didn't post it, I'd forget to. Might be > a fun quick hack for someone. It might just be worth it for double_rq_lock() - if you can sort out the deadlock potential Miklos just raised ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-07-24 10:59 UTC|newest] Thread overview: 255+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-07-20 17:44 [GIT]: Networking David Miller 2008-07-20 17:59 ` Arjan van de Ven 2008-07-20 23:52 ` David Miller 2008-07-21 20:32 ` David Miller 2008-07-21 0:54 ` Linus Torvalds 2008-07-21 1:03 ` David Miller 2008-07-21 1:09 ` Alexey Dobriyan 2008-07-21 1:14 ` David Miller 2008-07-21 1:22 ` Alexey Dobriyan 2008-07-21 2:40 ` Alexey Dobriyan 2008-07-21 2:48 ` David Miller 2008-07-21 5:11 ` David Miller 2008-07-21 9:48 ` Alexander Beregalov 2008-07-21 10:16 ` Ben Hutchings 2008-07-21 15:35 ` David Miller 2008-07-21 16:04 ` Alexander Beregalov 2008-07-21 11:57 ` Alexey Dobriyan 2008-07-21 15:27 ` David Miller 2008-07-21 16:49 ` Linus Torvalds 2008-07-21 16:53 ` David Miller 2008-07-21 1:20 ` Patrick McHardy 2008-07-21 11:28 ` Stefan Richter 2008-07-21 11:45 ` James Morris 2008-07-21 12:05 ` Patrick McHardy 2008-07-21 17:28 ` David Miller 2008-07-21 17:40 ` Linus Torvalds 2008-07-21 20:33 ` Patrick McHardy 2008-07-23 23:42 ` David Miller 2008-07-21 1:07 ` Linus Torvalds 2008-07-21 1:17 ` David Miller 2008-07-21 1:17 ` David Miller 2008-07-21 8:36 ` iwlwifi: fix build bug in "iwlwifi: fix LED stall" Ingo Molnar 2008-07-21 10:02 ` Winkler, Tomas 2008-07-21 10:53 ` Ingo Molnar 2008-07-21 12:12 ` [PATCH] iwlwifi: RS small compile warnings without CONFIG_IWLWIFI_DEBUG Tomas Winkler 2008-07-21 12:12 ` [PATCH] iwlwifi: " Tomas Winkler 2008-07-21 12:12 ` [PATCH] iwlwifi: compilation error when CONFIG_IWLWIFI_DEBUG is not set Tomas Winkler 2008-07-21 13:30 ` [crash, bisected] Kernel BUG at ffffffff8079afb1 (__netif_schedule()) Ingo Molnar 2008-07-21 13:45 ` [crash] BUG: unable to handle kernel NULL pointer dereference at 0000000000000370 Ingo Molnar 2008-07-21 14:30 ` Ingo Molnar 2008-07-21 15:04 ` Ingo Molnar 2008-07-21 15:24 ` David Miller 2008-07-21 18:18 ` Ian Schram 2008-07-21 19:06 ` Ingo Molnar 2008-07-21 19:13 ` Larry Finger 2008-07-21 19:13 ` Larry Finger 2008-07-21 19:34 ` Ingo Molnar 2008-07-21 19:34 ` Ingo Molnar 2008-07-21 19:43 ` Larry Finger 2008-07-21 19:43 ` Larry Finger 2008-07-21 19:47 ` Linus Torvalds 2008-07-21 19:47 ` Linus Torvalds 2008-07-21 20:15 ` David Miller 2008-07-21 20:28 ` Larry Finger 2008-07-21 20:28 ` Larry Finger 2008-07-21 20:21 ` David Miller 2008-07-21 20:21 ` David Miller 2008-07-21 20:38 ` Larry Finger 2008-07-21 20:38 ` Larry Finger 2008-07-21 20:46 ` David Miller 2008-07-21 20:51 ` Patrick McHardy 2008-07-21 21:01 ` David Miller 2008-07-21 21:06 ` Patrick McHardy 2008-07-21 21:35 ` Patrick McHardy 2008-07-21 21:35 ` Patrick McHardy 2008-07-21 21:42 ` Patrick McHardy 2008-07-21 21:42 ` Patrick McHardy 2008-07-21 21:51 ` Larry Finger 2008-07-21 21:51 ` Larry Finger 2008-07-21 22:04 ` Patrick McHardy 2008-07-21 22:04 ` Patrick McHardy 2008-07-21 22:40 ` Larry Finger 2008-07-21 22:40 ` Larry Finger 2008-07-21 23:15 ` David Miller 2008-07-21 23:15 ` David Miller 2008-07-22 6:34 ` Larry Finger 2008-07-22 10:51 ` Jarek Poplawski 2008-07-22 10:51 ` Jarek Poplawski 2008-07-22 11:32 ` David Miller 2008-07-22 12:52 ` Larry Finger 2008-07-22 20:43 ` David Miller 2008-07-22 13:02 ` Larry Finger 2008-07-22 14:53 ` Patrick McHardy 2008-07-22 14:53 ` Patrick McHardy 2008-07-22 21:17 ` David Miller 2008-07-22 21:17 ` David Miller 2008-07-22 16:39 ` Kernel WARNING: at net/core/dev.c:1330 __netif_schedule+0x2c/0x98() Larry Finger 2008-07-22 16:39 ` Larry Finger 2008-07-22 17:20 ` Patrick McHardy 2008-07-22 17:20 ` Patrick McHardy 2008-07-22 18:39 ` Larry Finger 2008-07-22 18:44 ` Patrick McHardy 2008-07-22 19:30 ` Larry Finger 2008-07-22 19:30 ` Larry Finger 2008-07-22 23:04 ` David Miller 2008-07-23 6:20 ` Jarek Poplawski 2008-07-23 7:59 ` David Miller 2008-07-23 8:54 ` Jarek Poplawski 2008-07-23 8:54 ` Jarek Poplawski 2008-07-23 9:03 ` Peter Zijlstra 2008-07-23 9:03 ` Peter Zijlstra 2008-07-23 9:35 ` Jarek Poplawski 2008-07-23 9:35 ` Jarek Poplawski 2008-07-23 9:50 ` Peter Zijlstra 2008-07-23 9:50 ` Peter Zijlstra 2008-07-23 10:13 ` Jarek Poplawski 2008-07-23 10:13 ` Jarek Poplawski 2008-07-23 10:58 ` Peter Zijlstra 2008-07-23 11:35 ` Jarek Poplawski 2008-07-23 11:35 ` Jarek Poplawski 2008-07-23 11:49 ` Jarek Poplawski 2008-07-23 11:49 ` Jarek Poplawski 2008-07-23 20:16 ` David Miller 2008-07-23 20:43 ` Jarek Poplawski 2008-07-23 20:55 ` David Miller 2008-07-23 20:55 ` David Miller 2008-07-24 9:10 ` Peter Zijlstra 2008-07-24 9:10 ` Peter Zijlstra 2008-07-24 9:20 ` David Miller 2008-07-24 9:20 ` David Miller 2008-07-24 9:27 ` Peter Zijlstra 2008-07-24 9:27 ` Peter Zijlstra 2008-07-24 9:32 ` David Miller 2008-07-24 10:08 ` Peter Zijlstra 2008-07-24 10:08 ` Peter Zijlstra 2008-07-24 10:38 ` Nick Piggin 2008-07-24 10:55 ` Miklos Szeredi 2008-07-24 10:55 ` Miklos Szeredi 2008-07-24 11:06 ` Nick Piggin 2008-07-24 11:06 ` Nick Piggin 2008-08-01 21:10 ` Paul E. McKenney 2008-08-01 21:10 ` Paul E. McKenney 2008-07-24 10:59 ` Peter Zijlstra [this message] 2008-07-24 10:59 ` Peter Zijlstra 2008-08-01 21:10 ` Paul E. McKenney 2008-07-23 20:14 ` David Miller 2008-07-23 20:14 ` David Miller 2008-07-24 7:00 ` Peter Zijlstra 2008-07-24 7:00 ` Peter Zijlstra 2008-07-25 17:04 ` Ingo Oeser 2008-07-25 18:36 ` Jarek Poplawski 2008-07-25 18:36 ` Jarek Poplawski 2008-07-25 19:16 ` Johannes Berg 2008-07-25 19:34 ` Jarek Poplawski 2008-07-25 19:34 ` Jarek Poplawski 2008-07-25 19:36 ` Johannes Berg 2008-07-25 20:01 ` Jarek Poplawski 2008-07-26 9:18 ` David Miller 2008-07-26 9:18 ` David Miller 2008-07-26 10:53 ` Jarek Poplawski 2008-07-26 13:18 ` Jarek Poplawski 2008-07-26 13:18 ` Jarek Poplawski 2008-07-27 0:34 ` David Miller 2008-07-27 0:34 ` David Miller 2008-07-27 20:37 ` Jarek Poplawski 2008-07-27 20:37 ` Jarek Poplawski 2008-07-31 12:29 ` David Miller 2008-07-31 12:29 ` David Miller 2008-07-31 12:38 ` Nick Piggin 2008-07-31 12:38 ` Nick Piggin 2008-07-31 12:44 ` David Miller 2008-08-01 4:27 ` David Miller 2008-08-01 7:09 ` Peter Zijlstra 2008-08-01 7:09 ` Peter Zijlstra 2008-08-01 6:48 ` Jarek Poplawski 2008-08-01 7:00 ` David Miller 2008-08-01 7:00 ` David Miller 2008-08-01 7:01 ` Jarek Poplawski 2008-08-01 7:01 ` David Miller 2008-08-01 7:01 ` David Miller 2008-08-01 7:41 ` Jarek Poplawski 2008-07-25 6:20 ` [lockdep warning] AOE / networking: aoenet_xmit: noop_qdisc.q.lock, INFO: inconsistent lock state at 0000000000000370 Ingo Molnar 2008-07-25 6:25 ` David Miller 2008-07-25 7:26 ` Ingo Molnar 2008-07-25 8:23 ` David Miller 2008-07-21 15:10 ` [crash] BUG: unable to handle kernel NULL pointer dereference " David Miller 2008-07-21 15:10 ` David Miller 2008-07-21 15:10 ` David Miller 2008-07-21 18:23 ` [crash] kernel BUG at net/core/dev.c:1328! Ingo Molnar 2008-07-21 18:35 ` Linus Torvalds 2008-07-21 18:46 ` Ingo Molnar 2008-07-21 19:30 ` Ingo Molnar 2008-07-22 11:21 ` [TCP bug] stuck distcc connections in latest -git Ingo Molnar 2008-07-22 13:45 ` David Newall 2008-07-22 13:57 ` Ingo Molnar 2008-07-22 14:54 ` David Newall 2008-07-22 15:34 ` Ingo Molnar 2008-07-22 21:12 ` Willy Tarreau 2008-07-23 8:26 ` Ingo Molnar 2008-07-24 6:04 ` [TCP bug, regression] " Ingo Molnar 2008-07-24 6:32 ` Ingo Molnar 2008-07-24 7:33 ` Willy Tarreau 2008-07-24 8:35 ` Ingo Molnar 2008-07-24 7:53 ` Herbert Xu 2008-07-24 8:24 ` Willy Tarreau 2008-07-24 8:27 ` Ingo Molnar 2008-07-24 8:36 ` David Miller 2008-07-24 9:05 ` Herbert Xu 2008-07-24 9:22 ` David Miller 2008-07-24 9:34 ` Ingo Molnar 2008-07-24 11:56 ` [regression] nf_iterate(), BUG: unable to handle kernel NULL pointer dereference Ingo Molnar 2008-07-24 11:59 ` Ingo Molnar 2008-07-24 12:03 ` Patrick McHardy 2008-07-24 12:22 ` Herbert Xu 2008-07-24 12:40 ` Pekka Enberg 2008-07-24 12:50 ` Herbert Xu 2008-07-24 12:56 ` Nick Piggin 2008-07-24 13:04 ` Herbert Xu 2008-07-24 13:13 ` Nick Piggin 2008-07-24 13:32 ` Pekka Enberg 2008-07-24 19:21 ` Matt Mackall 2008-07-25 9:09 ` Nick Piggin 2008-07-24 13:11 ` Matt Mackall 2008-07-24 14:37 ` Herbert Xu 2008-07-24 17:47 ` Matt Mackall 2008-07-25 1:39 ` Herbert Xu 2008-07-25 2:59 ` Matt Mackall 2008-07-24 12:44 ` Pekka Enberg 2008-07-24 12:49 ` Patrick McHardy 2008-07-24 13:23 ` Pekka Enberg 2008-07-24 13:31 ` Patrick McHardy 2008-07-24 13:34 ` Pekka Enberg 2008-07-24 18:51 ` Andrew Morton 2008-07-24 18:55 ` Pekka Enberg 2008-07-24 20:58 ` David Miller 2008-07-25 8:02 ` Dieter Ries 2008-07-25 10:41 ` Pekka Enberg 2008-07-24 19:35 ` Ingo Molnar 2008-07-26 16:09 ` Patrick McHardy 2008-07-26 17:34 ` Ingo Molnar 2008-07-26 13:43 ` Patrick McHardy 2008-07-24 21:13 ` Linus Torvalds 2008-07-24 22:09 ` David Miller 2008-07-26 13:47 ` Patrick McHardy 2008-08-01 21:10 ` Paul E. McKenney 2008-07-24 14:23 ` Ingo Molnar 2008-07-24 15:23 ` Patrick McHardy 2008-07-24 15:32 ` Ingo Molnar 2008-07-24 15:34 ` Patrick McHardy 2008-07-24 18:00 ` Krzysztof Oledzki 2008-07-24 13:01 ` [TCP bug, regression] stuck distcc connections in latest -git Willy Tarreau 2008-07-24 9:25 ` Ingo Molnar 2008-07-24 9:29 ` David Miller 2008-07-24 11:12 ` Herbert Xu 2008-07-24 9:36 ` Ilpo Järvinen 2008-07-24 10:03 ` Ilpo Järvinen 2008-07-21 19:00 ` [crash] kernel BUG at net/core/dev.c:1328! David Miller 2008-07-21 19:20 ` Stefan Richter 2008-07-21 20:11 ` David Miller 2008-07-21 21:26 ` Stefan Richter 2008-07-21 19:44 ` Ingo Molnar 2008-07-21 20:20 ` David Miller 2008-07-21 15:07 ` [crash, bisected] Kernel BUG at ffffffff8079afb1 (__netif_schedule()) David Miller 2008-07-21 13:50 ` [GIT]: Networking Ingo Molnar 2008-07-21 14:15 ` Stefan Richter
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1216897186.7257.279.camel@twins \ --to=peterz@infradead.org \ --cc=Larry.Finger@lwfinger.net \ --cc=akpm@linux-foundation.org \ --cc=davem@davemloft.net \ --cc=jarkao2@gmail.com \ --cc=kaber@trash.net \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-wireless@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=netdev@vger.kernel.org \ --cc=nickpiggin@yahoo.com.au \ --cc=paulmck@linux.vnet.ibm.com \ --cc=tglx@linutronix.de \ --cc=torvalds@linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.