[ovs-dev] [PATCH v4] ofproto-dpif-xlate: Implement RCU locking in ofproto-dpif-xlate.
wryan at vmware.com
Tue May 20 04:53:24 UTC 2014
So I did an experiment where I added 500 and 1000 ports and then deleted 500 and 1000 ports with and without this patch on both machines with 8 GB and 62 GB memory. Weirdly enough, adding / deleting ports with the RCU patch turned out to actually be faster than without. My only explanation here is taking the global xlate lock is expensive and / or 500 ports wasn't enough to induce memory pressure.
Here are the numbers for the 500 port case on a 8 GB memory machine:
WIth RCU patch:
Adding ports: real 1m15.850s
Deleting ports: real 1m21.830s
Without RCU patch:
Adding ports: real 1m28.357s
Deleting ports: real 1m33.277s
Member of Technical Staff
wryan at vmware.com
3401 Hillview Avenue, Palo Alto, CA
On May 19, 2014, at 8:56 AM, Ben Pfaff <blp at nicira.com> wrote:
> On Fri, May 16, 2014 at 06:59:02AM -0700, Ryan Wilson wrote:
>> Before, a global read-write lock protected the ofproto-dpif / ofproto-dpif-xlate
>> interface. Handler and revalidator threads had to wait while configuration was
>> being changed. This patch implements RCU locking which allows handlers and
>> revalidators to operate while configuration is being updated.
>> Signed-off-by: Ryan Wilson <wryan at nicira.com>
>> Acked-by: Alex Wang <alexw at nicira.com>
> One side effect of this change that I am a bit concerned about is
> performance of configuration changes. In particular, it looks like
> removing a port requires copying the entire configuration and that
> removing N ports requires copying the entire configuration N times. Can
> you try a few experiments with configurations that have many ports,
> maybe 500 or 1000, and see how long it takes to remove several of them?
> dev mailing list
> dev at openvswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev