On Fri, Jul 25, 2003 at 05:08:46PM -0700, Ben Greear wrote:
> Jeff Sipek wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >On Friday 25 July 2003 17:55, jw schultz wrote:
> >
>
> >>My thought would be to use 96bits for each counter. In-kernel
> >>code would run periodically doing something like this:
> >>
> >> curval = counter.in_kernel;
> >> /* get it in a register for atomicity */
> >> if (counter.user_low < curval)
> >> ++counter.user_high;
> >> counter.user_low = curval;
>
> What about every 30 seconds or so, detect wraps, and bump the 'high' counter
> if it wraps. (Check more often if you can wrap more than once in 30 secs).
Yes, how often the component needs run will depend on the
fastest counter.
> Then, upon read by user-space (or whatever needs 64-bit counters):
>
> 1) check wrap
> 2) grab low bits and OR them with the high bits.
> 3) check wrap again. If wrap happened, try again. Assumption is it could
> never wrap
> more than once during the time you are checking.
If you need to have userspace get instantaneous values it
would be more efficient to have userspace do the
update_64bit_counter code for just its counter than to have
multiple wrap checks.
> I think this could give us very low overhead, and extremely precise 64-bit
> reads. And, I think it would not need locks in the fast path..but I could
> also be missing something :)
Per-cpu counters. If this is done a variant of this for
per-cpu counters would be helpful. Per-cpu counters have
the advantage of reducing cache-line bouncing. I don't
think per-cpu counters should be used as a band-aid
(elasto-plast) for counter wrapping. Besides, how many
12Ghz 4-way hypertheaded (shared cache) CPUs do you need?
And if you only have one should you have per-cpu counters?
I don't think so.
-- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.wsRemember Cernan and Schmitt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jul 31 2003 - 22:00:27 EST