pcp
[Top] [All Lists]

Re: PCP patch for top/libgtop conversion

To: kaos@xxxxxxx (Keith Owens)
Subject: Re: PCP patch for top/libgtop conversion
From: "Albert D. Cahalan" <acahalan@xxxxxxxxxx>
Date: Tue, 26 Nov 2002 18:28:17 -0500 (EST)
Cc: acahalan@xxxxxxxxxx (Albert D. Cahalan), pcp@xxxxxxxxxxx, todd.c.davis@xxxxxxxxx, mmlnx@xxxxxxxxxx
In-reply-to: <27293.1038349467@xxxxxxxxxxxxxxxxxxxxx> from "Keith Owens" at Nov 27, 2002 09:24:27 AM
Sender: pcp-bounce@xxxxxxxxxxx
Keith Owens writes:
> "Albert D. Cahalan" <acahalan@xxxxxxxxxx> wrote:

>> 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.
>
> I disagree, any /proc file that reflects a kernel list structure and
> requires more than one read to get the data from /proc is subject to
> missing and/or duplicate entries.
>
> The problem is the lack of space in the "file pointer".  On 64 bit

The kernel has a per-fd struct that can hold a bit more data.
Results certainly may depend on implementation details of the
proc file being read. It's been a damn long time since procps
was commonly hurt by this problem when reading files. I never
seek to any position except the beginning, so the kernel can
cache all sorts of per-fd stuff to help out. Don't worry.

Reading the /proc directory itself is another matter. Due to
glibc defining an oversize directory entry structure, simply
reading the /proc directory will cause seeks. It's been quite
some time since I've heard complaints about this one though,
so maybe it has been fixed somehow. (new system call maybe?)
In any case, it's not a common problem.



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