Re: [PATCH, 2.5] : Adding counters to BSD process accounting

[Matti Aarnio <matti.aarnio@zmailer.org>]

On Mon, Jul 15, 2002 at 11:57:39AM +0530, Manik Raina wrote:
> This  patch  keeps account of the number of bytes read/written by a
> process in it's lifetime.
> 
> This may be a  good estimate of how IO bound a process is.
> This change is integrated with the BSD process accounting feature. Please
> review the changes and if you're ok with it, please apply to the 2.5 tree.

  Do have a deeper look into how the BSD ACCT works.

  Throwing in couple 8-byte scalars isn't quite right thing.
  The  pacct  file format (record size!) will change with this thing.

  There exist already fields:

        comp_t    ac_io;          /* Accounting Chars Transferred */
        comp_t    ac_rw;          /* Accounting Blocks Read or Written */

  Those are encoded with zero...


  If you comp_t encode the read/write data, you will be able to
  squeeze it into the reserved alignment bytes: ac_pad[].

  Well, that encoding counts up to 16 GB, only, but is better than 
  nothing.   The normal encoding routine handles "unsigned long"
  input value, not  __u64,  thus you would need to write a new
  encoder too.    Reading the existing  encode_comp_t()  shows,
  that its coder has mixed up EXPSIZE and EXPBASE concepts.


/* 
 *  comp_t is a 16-bit "floating" point number with a 3-bit base 8
 *  exponent and a 13-bit fraction. See linux/kernel/acct.c for the
 *  specific encoding system used.
 */

typedef __u16   comp_t;


  With 13 bits, the maximum fraction is thus  2^14 -1 = 16383
  With 3 bits, and base  8 the maximum exponent is:  8^7 =   2M
  With 3 bits, and base 16 the maximum exponent is: 16^7 = 256M

  Combined:
    Base8:  0 thru   16 GigaCounts  with 10-13 bit precission
    Base16: 0 thru 4096 GigaCounts  with  9-13 bit precission


> thanks,
> Manik
...

/Matti Aarnio