Re: reminder, 2.6.18 window...

[Phil Dibowitz <phil@ipom.com>]

[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]

On Thu, May 25, 2006 at 08:05:37AM -0500, Brent Cook wrote:
> > I'll admit to not knowing all the intricacies of the kernel coding
> > involved, but I don't offhand see how zeroing the stats would be
> > significantly more complex than updating the stats during normal usage. 
> > But I'll have to leave that argument to the experts.
> >
> 
> What it boils down to is that currently, a single CPU or thread ever touches 
> the stats concurrently, so it doesn't have to lock them or do anything 
> special to ensure that the continue incrementing. If you want to make sure 
> that the statistics actually reset when you want them to, you have to account 
> for this case:
> 
>   CPU0 reads current value from memory (increment)
>   CPU1 writes 0 to current value in memory (reset)
>   CPU0 writes incremented value to memory (increment complete)

Perhaps I'm missing something here, but these counters are only incrimented
in hardware... i.e. attomically.

And the reset I do is via a command register, which should also be atomic.

Now in a driver that was keeping this all in a local struct, I could
understand that need for locking, but in the skge case, and in fact in many
drivers I've looked at, the numbers are all kept in the hardware, incremented
by the hardware, as it gets packets.

So clearing them via command registershouldn't need locking as far as I can
tell.

But please, correct me if I'm wrong.

-- 
Phil Dibowitz                             phil@ipom.com
Freeware and Technical Pages              Insanity Palace of Metallica
http://www.phildev.net/                   http://www.ipom.com/

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
 - Benjamin Franklin, 1759


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]