pcp
[Top] [All Lists]

Re: PCP patch for top/libgtop conversion

To: pcp@xxxxxxxxxxx
Subject: Re: PCP patch for top/libgtop conversion
From: "Albert D. Cahalan" <acahalan@xxxxxxxxxx>
Date: Tue, 26 Nov 2002 05:28:52 -0500 (EST)
Cc: markgw@xxxxxxx, todd.c.davis@xxxxxxxxx, mmlnx@xxxxxxxxxx, kenmcd@xxxxxxxxxxxxxxxxx
Sender: pcp-bounce@xxxxxxxxxxx
Interesting thread I found on a web archive...
I'm making some libproc changes, so it's not a
bad time to consider what the API should look like.
Please Cc: me on any response.

> The copyout problem ... I think there remains a systemic Linux issue
> with any /proc "file" that is longer than your page size du jour ...
> if the underlying data is subject to change, there is no way a user
> space app (cat(1) is the simplest example) is guaranteed to see a
> consistent view ... you may miss whole lines, you may see some lines
> more than once.
>
> If this assertion is not correct, I'd like to understand why.

You're 1/3 right. The app won't get a perfect snapshot of the
data, but it won't get missing or duplicate lines either.
Reading X bytes moves the file pointer by Y and Y>=X.
For example, the file pointer may be encoded as:

5 bits  character-within-a-field (the least significant bits)
3 bits  field number
9 bits  line number

Plus any part of the data (one field, one line, etc.) could
be kept for the reader so that 9999 changing to 10000 doesn't
ever look like 99000 to the reader.

> The changes to top and libgtop to use PCP are essentially done, but I 
> don't yet have a way to release them.  We go through a formal process at 
> IBM to get permission to contribute to outside projects.  I don't have 
> permission to contribute to procps or libgtop.  I'll work on that.

Be glad you have such a process.

I don't have much of an idea what your project is doing, but it
seems that you pre-parse /proc files and then ship them over the
net to a hacked-up libproc. I wonder what you expect to do about
machine differences: page size, clock tick rate, word size...

Also, do you cache stuff in a local daemon? Do you have an async
interface?

I'm interested in suggestions for a public libproc API.
Right now the interface is totally volatile. Some part of
that needs to get cleaned up for non-procps use. Let me
know if there's an existing API that you'd like to have.

Warning: the kernel interface is more volatile than it looks;
you should consider using libproc on the data-collection side
once libproc exports something you can rely on.

For those that don't know, procps-3.1.1 is out now.
http://procps.sf.net/

<Prev in Thread] Current Thread [Next in Thread>