* David Miller <[EMAIL PROTECTED]> wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Sat, 16 Feb 2008 11:26:18 -0800
>
> > On Sat, 16 Feb 2008 13:03:54 +0100 Eric Dumazet <[EMAIL PROTECTED]> wrote:
> >
> > > Yes, per connection basis. Some workloads want to open/close more
> > > than 10
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Sat, 16 Feb 2008 11:26:18 -0800
> On Sat, 16 Feb 2008 13:03:54 +0100 Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> > Yes, per connection basis. Some workloads want to open/close more than 1000
> > sockets per second.
>
> ie: slowpath
Definitely not s
On Sat, 16 Feb 2008 11:26:18 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > indirect functions calls are everywhere in kernel, network, fs,
> > everywhere.
>
> That doesn't make them fast.
just to emphasize this: an indirect function call is at least as expensive as
an atomic operation on
iable in its present networking application or indeed in any future
ones.
I have no benchmarks, but real workloads where it matters, and where userland
eats icache/dcache all the time.
It is even clearly stated at the top of include/linux/pcounter.h
/*
* Using a dynamic per
op%edi
> c02146e6: 5d pop%ebp
> c02146e7: c3 ret
>
>
> Once it is better, just make pcounter vanish.
Some of the stuff in there is from the __percpu_disguise() thing which we
probably can live without.
But I'd be su
,(%eax)
c02146e2: 58 pop%eax
c02146e3: 5b pop%ebx
c02146e4: 5e pop%esi
c02146e5: 5f pop%edi
c02146e6: 5d pop%ebp
c02146e7: c3 ret
- First up, why was this added at all? We have percpu_counter.h which
has several years development invested in it. afaict it would suit the
present applications of pcounters.
If some deficiency in percpu_counters has been identified, is it
possible to correct that deficiency rather tha
On Mon, 04 Feb 2008 16:20:35 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Mon, 4 Feb 2008 01:44:02 -0800
>
> > Please do not merge pieces of generic kernel infrastructure while
> > keeping it all secret on the netdev list. Ever.
>
> It wa
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Mon, 4 Feb 2008 01:44:02 -0800
> Please do not merge pieces of generic kernel infrastructure while
> keeping it all secret on the netdev list. Ever.
It was so damn secret that it sat in your -mm tree for months.
Don't be rediculious Andrew.
--
To un
e7d0362dd41e760f340c1b500646cc92522bd9d5 should have been folded into
de4d1db369785c29d68915edfee0cb70e8199f4c prior to merging. We now and for
ever have a window of breakage which screws up git bisection. Which I
just hit. Which is the only reason I discovered the file's existence.
Please do
10 matches
Mail list logo
