This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] PPC64 enable hp-timing
- From: Steve Munroe <sjmunroe at us dot ibm dot com>
- To: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>
- Cc: decimal at us dot ibm dot com, libc-alpha at sources dot redhat dot com, Thomas Gall <tgall at us dot ibm dot com>
- Date: Wed, 26 Oct 2005 10:18:57 -0500
- Subject: Re: [PATCH] PPC64 enable hp-timing
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 10/25/2005
06:17:59 PM:
> 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.
Ok with the current /proc/cpuinfo format a 64-way would run about 9380
bytes and the timebase value will be near the end. I'll submit a updated
patch.
The other platforms will have to decide if they have a problem based on
the format of their /proc/cpuinfo and the maximum processor configuration.
For example on i386 the "cpu MHz" line its repeated for each processor so
a 4K buffer should be enough.
Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center