Re: [RFC] A new SPI API for fast, low-latency regmap peripheral access

[Andrew Lunn <andrew@xxxxxxx>]

> > Or otherwise make it unobtrusive (eg, with similar techniques to those
> > used by the networking API).
> 
> I just tried this out by re-writing the statistics code using u64_stats_sync
> and per-cpu statistics, which get totaled on sysfs read access as Andrew Lunn
> suggested.
> The results are truly amazing!
> 
> The overhead caused by statistics in my test dropped from 43us to just 1-2us.

When you are potentially dealing with 10 million packets a second, you
cannot spend long on each individual packet incrementing a counter...

> This was tested on a 64-bit machine though, so I don't know how it will affect
> 32-bit systems. Nor do I have an easy means of testing this. Any ideas?

It does make a difference. On a 64 system, you can increment a counter
in a single instruction so you either see the old value, or the new
value. With 32 bit systems, which needs multiple instructions to
increment the counter, so the code takes are you cannot see anything
odd when it needs to overflow from the lower 32bits into the upper 32
bits. So 32bit systems will be a little bit more expensive. However,
not by a lot.

> Also, I have converted all the struct spi_statistics members to u64_stats_t.
> It was easier to test this way. Some of the original types were unsigned long,
> which can have different sizes on 64bit or 32bit systems... is that
> intentional?

You can keep with uint32, if you want to, and keep with the sequence
counter style locking. For networking, 32bit counters can wrap around
pretty fast, so the main counters are 64 bit. But the concept works
O.K. for smaller types.

     Andrew