This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] PPC64 enable hp-timing
- From: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>
- To: sjmunroe at us dot ibm dot com
- Cc: libc-alpha at sources dot redhat dot com, decimal at us dot ibm dot com, Thomas Gall <tgall at us dot ibm dot com>
- Date: Wed, 26 Oct 2005 09:17:59 +1000
- Subject: Re: [PATCH] PPC64 enable hp-timing
- References: <OFA5CC9354.92B7BF7B-ON862570A5.007F22D6-862570A5.007FE20C@us.ibm.com>
On Tue, 2005-10-25 at 18:16 -0500, Steve Munroe wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 10/25/2005
> 05:51:33 PM:
>
> > On Tue, 2005-10-25 at 15:59 -0500, Steven Munroe wrote:
> >
> > > +
> > > + fd = open ("/proc/cpuinfo", O_RDONLY);
> > > + if (__builtin_expect (fd != -1, 1))
> > > + {
> > > + /* XXX AFAIK the /proc filesystem can generate "files" only up
> > > + to a size of 4096 bytes. */
> >
> > I think that assumption isn't true. The seq_file mecanism deals
> > transparently with that nowadays...
> >
> Well if this is a problem, i386, ia64, and x86_64 have it too. They are
> all implemented the same way. sparc64 uses an 8K buffer.
Well, if there is a limit in proc, it's not 4K put PAGE_SIZE (which can
be different, see the 64K pages patches for ppc64 for example), but
while simple proc stuff do have this limit, it's not absolute, and
things using the new seq_* API (that is pretty much everything nowadays)
can easily cross the page size limit.
Also, I think we _will_ reach this limit. Take a 64 cores POWER5 box,
for example, with the 2 threads it gives you 128 CPU entries
in /proc/cpuinfo. That gives you barely 32 bytes per CPU not even
counting the timebase entry (and other possible additional ones). That
is not enough.
Thus I think we will break if you limit the parsing to a 4k buffer.
Ben.