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


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.



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