[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1283373495.2484.41.camel@edumazet-laptop>
Date: Wed, 01 Sep 2010 22:38:15 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Christoph Lameter <cl@...ux.com>
Cc: Nitin Gupta <ngupta@...are.org>,
Pekka Enberg <penberg@...helsinki.fi>,
Minchan Kim <minchan.kim@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg KH <greg@...ah.com>,
Linux Driver Project <devel@...verdev.osuosl.org>,
linux-mm <linux-mm@...ck.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 03/10] Use percpu stats
Le mercredi 01 septembre 2010 à 15:05 -0500, Christoph Lameter a écrit :
> The problem only exists on 32 bit platforms using 64 bit counters. If you
> would provide this functionality for the fallback case of 64 bit counters
> (here x86) in 32 bit arch code then you could use the this_cpu_*
> operations in all context without your special code being replicated in
> ohter places.
>
> The additional advantage would be that for the 64bit case you would have
> much faster and more compact code.
>
>
My implementation is portable and use existing infrastructure, at the
time it was coded. BTW, its fast on 64bit too. As fast as previous
implementation. No extra code added. Please double check.
If you believe you can do better, please do so.
Of course, we added 64bit network stats to all 32bit arches only because
cost was acceptable. (I say all 32bit arches, because you seem to think
only x86 was the target)
Using this_cpu_{add|res}() fallback using atomic ops or spinlocks would
be slower than actual implemenation (smp_wmb() (nops on x86) and
increments).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists