[PATCH] staging: octeon: use atomic_long_t

Greg Kroah-Hartman gregkh at linuxfoundation.org
Fri Feb 19 18:17:54 UTC 2016


On Fri, Feb 19, 2016 at 10:08:07AM -0800, David Daney wrote:
> On 02/18/2016 03:45 PM, Greg Kroah-Hartman wrote:
> >On Fri, Feb 19, 2016 at 12:20:45AM +0200, Aaro Koskinen wrote:
> >>Use atomic_long_t, so that we can avoid some 32 vs. 64-bit ifdeffery.
> >
> >Why are these atomic at all?  There's no reason they can't just be a
> >u64 like all other network drivers have, right?
> 
> In the original code, they were incremented by multiple threads/CPUs, so
> atomic operations perform better than putting a spinlock around the whole
> thing.
> 
> If the invariant holds that there is exactly one napi_struct per net_device,
> then the atomic business may not be necessary.  There is still the
> possibility of whatever is reading the statistics racing with the update,
> but perhaps that doesn't matter.

I don't think that matters, the stats are there just to see what is
happening at a macro level, look at all of the other network drivers in
the kernel, they don't need a lock or an atomic type for this type of
statistic from what I can tell.

thanks,

greg k-h


More information about the devel mailing list