This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] PPC64 enable hp-timing 3rd try
- From: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>
- To: Steven Munroe <munroesj at us dot ibm dot com>
- Cc: libc-alpha at sources dot redhat dot com, Tom Gall <tgall at us dot ibm dot com>, Dwayne McConnell <decimal at us dot ibm dot com>
- Date: Sun, 30 Oct 2005 09:27:58 +1100
- Subject: Re: [PATCH] PPC64 enable hp-timing 3rd try
- References: <43600265.1030702@us.ibm.com>
On Wed, 2005-10-26 at 17:25 -0500, Steven Munroe wrote:
> This version uses malloc to allocate a 16k buffer in __get_clockfreq.
>
> Looks like the current 64 cpu systems with SMT can generate a
> /proc/cpuinfo of around 9K. As timebase is near the end of the file we
> need at least that much to guarentee we will find the timebase value. We
> can expect to see bigger systems in the future so we will allocate a 16K
> buffer to be sure. Because we are pushing PTHREAD_STACK_MIN, we use
> malloc for the buffer instead of using stack space.
Hrm... I don't like it. If we release a system with twice as much CPUs
(and that's not at all improbable), it will break again...
I suggest you either do something with multiple passes. That is, for
example, allocate a 16k buffer, and if read doesn't return a short read
(you didn't EOF), then try again with a 32k buffer etc...
I really don't like the hard coded value that will lead into some dodgy
silent failures in the future.
Ben.