Acked-by: Ethan Jackson <et...@nicira.com>
On Tue, Mar 5, 2013 at 4:28 PM, Ben Pfaff <b...@nicira.com> wrote: > With CFM enabled on 1000 tunnels, this reduced CPU use from about 30% to > about 22%. > > Signed-off-by: Ben Pfaff <b...@nicira.com> > --- > lib/timeval.h | 18 ++++++------------ > 1 files changed, 6 insertions(+), 12 deletions(-) > > diff --git a/lib/timeval.h b/lib/timeval.h > index 5a7b6e2..d5c12f0 100644 > --- a/lib/timeval.h > +++ b/lib/timeval.h > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2008, 2009, 2010, 2011, 2012 Nicira, Inc. > + * Copyright (c) 2008, 2009, 2010, 2011, 2012, 2013 Nicira, Inc. > * > * Licensed under the Apache License, Version 2.0 (the "License"); > * you may not use this file except in compliance with the License. > @@ -45,18 +45,12 @@ BUILD_ASSERT_DECL(TYPE_IS_SIGNED(time_t)); > * much time will be wasted in signal handlers and calls to > clock_gettime(). */ > #define TIME_UPDATE_INTERVAL 100 > > -/* True on systems (particularly x86-64 Linux) where clock_gettime() is > - * inexpensive. On these systems, we don't bother caching the current > time. > - * Instead, we consult clock_gettime() directly when needed. > - * > - * False on systems where clock_gettime() is relatively expensive. On > these > - * systems, we cache the current time and set up a periodic SIGALRM to > remind > - * us to update it. > - * > - * Also false on systems (e.g. ESX) that don't support setting up timers > based > - * on a monotonically increasing clock. */ > +/* True on systems that support a monotonic clock. Compared to just > getting > + * the value of a variable, clock_gettime() is somewhat expensive, even on > + * systems that try hard to optimize it (such as x86-64 Linux), so it's > + * worthwhile to minimize calls via caching. */ > #ifndef CACHE_TIME > -#if defined ESX || (defined __x86_64__ && defined LINUX_DATAPATH) > +#if defined ESX > #define CACHE_TIME 0 > #else > #define CACHE_TIME 1 > -- > 1.7.2.5 > > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev >
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
