On Wed, Mar 19, 2014 at 03:36:12PM -0700, Pravin Shelar wrote: > On Wed, Mar 19, 2014 at 3:29 PM, Ben Pfaff <[email protected]> wrote: > > On Wed, Mar 19, 2014 at 03:16:37PM -0700, Pravin Shelar wrote: > >> On Wed, Mar 19, 2014 at 11:08 AM, Ben Pfaff <[email protected]> wrote: > >> > On Tue, Mar 18, 2014 at 01:53:27PM -0700, Pravin wrote: > >> > Polling the atomic variable only every 67,108,864 times through the > >> > loop seems pretty conservative. (Does that even poll once a second?) > >> > > >> I am not sure how to calculate one second in this loop efficiently. > >> But I will try to use poll() rather than atomic variable here. > > > > All I mean is that 64 million is a very large number and seems like it > > might introduce a long delay, especially if packets are arriving > > quickly. If we reduce the number to, say, 1000, does it slow > > operation down too much? > > > If I drop to 1000, I am pretty sure that performance will go down. > Last time I checked this value need to be in million on bare metal > machine. > I am not worried about delay, since it only affects how soon we start > polling device once we add it to datapath. That should be rare > operation.
I think that's because a bare atomic_read() is unnecessarily expensive. (It generates a "lock" prefix.) Can you try atomic_read_explicit() with memory_order_consume instead? That's good enough for RCU and in my tests it generates exactly the same code as a non-atomic read on x86 with GCC 4.7 or with Clang. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
