lkml.org 
[lkml]   [2009]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateSat, 11 Apr 2009 08:05:54 -0700
FromStephen Hemminger <>
SubjectRe: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
On Sat, 11 Apr 2009 09:08:54 +0200
Ingo Molnar <mingo@elte.hu> wrote:

>
> * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
>
> > I will nevertheless suggest the following egregious hack to
> > get a consistent sample of one counter for some other CPU:
> >
> > a. Disable interrupts
> > b. Atomically exchange the bottom 32 bits of the
> > counter with the value zero.
> > c. Atomically exchange the top 32 bits of the counter
> > with the value zero.
> > d. Concatenate the values obtained in (b) and (c), which
> > is the snapshot value.
>
> Note, i have recently implemented full atomic64_t support on 32-bit
> x86, for the perfcounters code, based on the CMPXCHG8B instruction.
>
> Which, while not the lightest of instructions, is still much better
> than the sequence above.
>
> So i think a better approach would be to also add a dumb generic
> implementation for atomic64_t (using a global lock or so), and then
> generic code could just assume that atomic64_t always exists.
>
> It is far nicer - and faster as well - as the hack above, even on
> 32-bit x86.
>
> Ingo

The iptables counters are write mostly, read rarely so they don't
fit the seq counter or atomic use case. Also, it is important
to get a consistent snapshot of the whole set not just each
individual counter.


\
 
 \ /
  Last update: 2009-04-11 17:09    [from the cache]
©2003-2010