On Fri, 2012-05-25 at 18:43 -0400, Steven Rostedt wrote: > On Sat, 2012-05-26 at 00:31 +0200, Thomas Gleixner wrote: > > On Thu, 24 May 2012, Steven Rostedt wrote: > > > > > On Thu, 2012-05-24 at 04:28 +0000, Jain Priyanka-B32167 wrote: > > > > Waiting for review comments on this. > > > > > > > > > > > diff --git a/net/core/dev.c b/net/core/dev.c index 452db70..4017820 100644 > > > > --- a/net/core/dev.c > > > > +++ b/net/core/dev.c > > > > @@ -2940,7 +2940,7 @@ int netif_rx(struct sk_buff *skb) > > > > struct rps_dev_flow voidflow, *rflow = &voidflow; > > > > int cpu; > > > > > > > > - preempt_disable(); > > > > + migrate_disable(); > > > > > > I really want to avoid placing open coded migrate_disable() around the > > > kernel. Perhaps we should use "get_cpu_light()" here too. > > > > No. get_cpu_light() and migrate_disable() are different. > > > > Following your argument we would have to replace preempt_disable() > > with get_cpu() all over the place. > > > > I didn't like the get_cpu_light either, but I thought it was Peter that > was against a 'migrate-disable()' API leaking all over the kernel. > > IIRC, he gave in when it was part of a locking internal infrastructure. > Now it's coming to what he was against. Maybe he changed his mind. I'll > let him speak for himself. Ah, right, so I've mapped migrate_disable() to preempt_disable() for ! PREEMPT_RT. This to make sure people don't do stupid things with it :-) Then again, people do lots of stupid things with preempt_disable() too, but at least we don't grow actual migrate_disable() abuse. I think I've done one or two migrate_disable() site like the proposed in -rt already. The thing I really want to avoid is introducing a migrate_disable() that can schedule for !rt. -- 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
