This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]