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

Matti Aarnio (matti.aarnio@zmailer.org)
Mon, 15 Jul 2002 13:50:43 +0300


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