lkml.org 
[lkml]   [2003]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Net device byte statistics
-----BEGIN PGP SIGNED MESSAGE-----
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

Jeff.

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

iD8DBQE/IbSPwFP0+seVj/4RAgpoAKCZm4eswdJ+iPJZdsvlhUGXyfJZYACfVwyl
4dIfHzaufhuGSMFt2ZDd5Vg=
=iVm4
-----END PGP SIGNATURE-----

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.096 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site