Steven Rostedt wrote:
On Mon, 11 Aug 2008, David Miller wrote:From: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> Date: Mon, 11 Aug 2008 23:09:38 +0200On Mon, 2008-08-11 at 14:00 -0700, David Miller wrote:From: "John Kacur" <jkacur@xxxxxxxxx> Date: Mon, 11 Aug 2008 15:11:46 +0200__qdisc_run() calls qdisc_restart() which calls handle_dev_cpu_collision(skb, dev, q); and then the problem shows up here: __get_cpu_var(netdev_rx_stat).cpu_collision++; The solution is to disable interrupts around the above increment. Here is an attached patch to do so. (Thank's to Peter Zijlstra for help in the analysis and dropping the answer in my lap, so if I got it right it is due to his help, but if I messed it up, then I did that part all by myself.)__qdisc_run() always runs in software interrupt context, so I guess this is some problem with the -rt stuff running software interrupts in threads?Hmm, good point - and those threads should be cpu affine on -rt if I'm not mistaken. Steven, do you happen to remember details?The key issue is whether those threads run software interrupts in a compatible environment. And such a proper environment allows plain smp_processor_id() without any special preparations.Yes, we have a softirq thread per CPU. We should have a test in the smp_processor_id for rt to not bug if it is called by known "per_cpu" threads.
something like #ifdef CONFIG_PREEMPT_RT WARN_ON(!in_atomic() && current->rt.nr_cpus_allowed > 1); #else WARN_ON(!in_atomic()); #endifwould probably work and be fairly efficient. Of course nr_cpus_allowed technically could be adjusted at any time, so perhaps not. Its probably good enough for a warning check, however.
-- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
signature.asc
Description: OpenPGP digital signature
