RE: [Lse-tech] topology design notes

[Patrick M. <mo...@os...>]

On Wed, 5 Dec 2001, Luck, Tony wrote:

> Paul Jackson wrote:
> > On Tue, 4 Dec 2001, Patrick Mochel wrote:
> >
> > > Plus, I maintain that parsing ascii is not _that_
> > > expensive. We're talking about fast, modern machines. If
> > > you're seeing _serious_ performance hits, I'm an interested
> > > to see just what it is you're trying to do..
> >
> > I think Neils might be doing something like collecting
> > performance trace data, in quantity.  If so he would need to
> > be pretty careful to minimize the cpu cycles per datum.
> >
> > This seems quite distinct from the problem of describing the
> > (relatively) static topology of a system - its devices, cpus
> > and memory and their connectivity.
>
> Cpu time for a round-trip from binary to ascii and back
> using:
>
> 	sprintf(buf, "%ld", lval); lval = atol(buf);
>
> on an 800 MHz IA-64 is between 1.86 microsends and 3.60
> microseconds depending linearly on the number of digits
> required to represent the number.  You could probably cut
> that time in half at least with more efficient code to
> turn numbers into strings (the expensive part) and back.
>
> This would indicate that when the frequency of use gets
> up to about 4000/sec then the overhead will reach 1% (with
> average length 7 digit numbers, and using the sprintf/atol
> code ) ... which is where you might start to detect it with
> macro level benchmarks.
>
> Niels talked about trace data with "hundreds of thousands of
> records per second" ... he definitely shouldn't use ascii for
> that! But for system topology information which should only
> be read at most once per process creation, it looks like ascii
> won't hurt in any noticeable way.

I'm seeing about 1.35 usecs for unsigned long (32 bits) and 1.66 usecs for
unsigned long long (64 bit) on a 1 Ghz P-III. (And that's with a memcpy
between the sprintf and strtoul to (poorly) simulate copy_to_user()).
But, I digress...

I'll give in and say that the format of the file doesn't _have_ to be
ascii. It would be nice so anyone could read it. But, there is nothing
mandating it (yet).

This allows one to copy binary data to/from kernel space using the
filesystem, so we still obviate the need for two separate interfaces. :)


	-pat