Elmar Pruesse wrote:
/proc/cpuinfo exists on both RHEL5 and SLES10 machines I have at
hand. Does it exist on your machine? If you run "cat /proc/cpuinfo >
/tmp/t; ls -l /tmp/t" what size do you see? What kind of machine are
you running on (number of CPUs, etc)?
/proc/cpuinfo exists on every linux kernel I have seen in a long time,
it should be present in all current distros.
The size is 24790 bytes for a 32 core machine. The issue also appears on
the 16 core machine. However, I think this message first turned up when
we got the 4-core CPUs. So it might be related to the file size (before
both machines were 8 core total).
Look at the strace dump I sent in my first mail. It shows the system
calls leading up to the error message. It sucessfully opens the file,
allocates a 4kb thread-private memory block, and begins a read-loop on
the file descriptor with a 10k buffer (stack I guess). The kernel
returns only 5 stanzas worth of file content, probably because it's own
buffer is page-sized. Interestingly, the second time round the buffer
size announced to read is decremented by 4k instead of just 3870. After
the buffer is (apparently) full, a last read is issued with only 1k. The
4k allocated before are freed and the error message is written to the log.
No, you've found a bug. The code does a single fread of 10k. fread may
be doing larger stdio-buffered reads internally - that's probably what
you're seeing. The code then checks and if the read filled the buffer
it errors out, which is what the message is showing. Obviously broken.
I've opened a bug report - CR 6747147 "Group Manager LB algorithm reads
insufficient data from /proc/cpuinfo". Here's the description I entered:
There is code in
src/server/auth/utauthd/GroupManager.c:get_system_capacity() that, on
Linux, reads 10K of data from /dev/cpuinfo. If the read fills the
buffer, it fails and doesn't return information like number of CPUs
and clock speeds to be used in the Load Balancing heuristic.
Unfortunately, on modern machines much more data is read from
cpuinfo. For example, 24K of data is returned on a 32-core machine
(according to a customer - I don't have such a large machine to test
with). The code needs to be more flexible and deal with larger reads.
Thanks,
Bob
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
