Re: [PATCH] staging: octeon: use atomic_long_t

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux