[lkml]   [2003]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Net device byte statistics
    Hash: SHA1

    On Friday 25 July 2003 17:55, jw schultz wrote:
    > I've been watching this discussion for several months. If i
    > may, let me summarise what i see as the salient points.
    > 1. Uptime is such that many 32bit counters wrap.
    > 2. Userspace can easily detect wrapping when
    > measuring deltas. Provided it only wraps once.
    > 3. Some counters can wrap at intervals so small that
    > userspace cannot accurately detect the wrap without
    > the monitoring tool becoming a significant system
    > load.

    Exactly, this is why I think that we should make the counters 64-bits right
    now, so that we don't have to worry about them later - when it will be
    required to have them 64-bits long.

    > 4. 64bit counters would be sufficient. At least for
    > most of these counters.
    > 6. Without atomicity the counters will have windows
    > where they report garbage. And if the code paths
    > writing the counter aren't otherwise protected they
    > can likewise corrupt the counter.
    > 5. The locking overhead needed for atomicity of
    > 64bit counters on 32bit architectures is excessive
    > for fast-paths.

    Per cpu variables with global overflow seem to be the way to go (at least for
    the network statistics.)

    > It seems to me that what is needed is a in-kernel component
    > that can intermediate between internal 32bit counters and
    > userspace-visible 64bit (or larger) counters. This
    > component would need to be active often enough that the
    > counters don't wrap without detection and so that userspace
    > will see sufficiently accurate numbers.

    Very interesting, the same thing that "was supposed to be done" in user space,
    but modular and in the kernel itself...I am impressed.

    > 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;
    > This code would run every N jiffies or be in a high priority
    > kernel thread. As an in-kernel service it could loop over a
    > set of counters that have been registered with it. If
    > needed you could even have user_high be larger than 32 bits.
    > It could even be possible to make the code accessing the
    > userspace counter fall-back to the kernel one if the 64bit
    > counter is zero. That way registration could potentially be
    > userspace triggered.
    > This is just the acorn of an idea. It does mean that
    > userspace visible counters will not have instantaneous
    > resolution but it seems to me that HZ should be more than
    > tight enough. There are certainly other ways to achieve
    > this and implementation should take into account cache
    > effects.

    Overall, great idea!

    We basically have a choice:

    - - 32-bit counters with overflows every 4GB and instantenious (sp?) stats
    - - 64-bit counters with overflows every 16PB and possibility of stats being off
    a bit


    - --
    *NOTE: This message is ROT-13 encrypted twice for extra protection*
    Version: GnuPG v1.2.2 (GNU/Linux)

    -----END PGP SIGNATURE-----

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:47    [W:0.024 / U:9.888 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site