Re: [Perfctr-devel] Re: [perfmon] perfmon2 code review: 32-bit ABI on 64-bit OS

On Sat, Feb 11, 2006 at 02:33:54PM -0800, Stephane Eranian wrote:
Hello,

On Sun, Feb 12, 2006 at 12:16:25AM +0600, Philip Mucci wrote:

On some 64-bit arches (e.g. x86_64), most userspace code is 64-bit,
while on others (e.g. powerpc), most is 32-bit. Reducing the number of
things that a userspace tool or library writer can trip over seems like
a good thing here, even if it slightly complicates perfmon's internals.

Note that there are similar issues with the remapped sampling buffer.
There, you need to explicitly compile your tool with a special option
to force certain types to be 64-bit (size_t, void *).

It's pretty normal to just use 64-bit quantities in these cases, and
cast appropriately.

I agree with Bryan. Stephane, do you have any quantitative data for how
much more expensive going to 64 bit quantities would be? Which
performance critical operations access this structure? AFAIK, any
performance monitoring system call is already slow by nature...and thus
an additional dozen cycles isn't going to make a difference. Of course,
if this structure needs to be read/written by get_pmd, including the
userspace version (+ mmap offset), then the extra overhead should be
considered.

I think I can easily convert the bitmasks to be u64 on all platforms.
I don't think it will negatively impact performance on 32-bit applications.

The sampling buffer is another matter. It is directly remapped. The default
format, exposes size_t and void *. The size_t is not on the critical
path, it is used to specify the buffer size. If we expose as 64-bit,
we need to check on 32-bit system that the value is below 4GB and cast
to size_t.

The most challenging piece is the IP (program pointer) that is in every
sample. Today it is defined as unsigned long because this is fairly
natural for a code address. The 64bit OS captures addresses as 64-bit,
the 32-bit monitoring tool running on top has to consume them as 64-bit
addresses, so u64 would be fine.

But not on a 32-bit kernel with a 32-bit tool, addresses exported as u64
would certainly work but consume double to buffer space, and that is a
more serious issue in my mind.

Hmm.. does the sampling buffer collect on userspace PC values, or
kernel ones as well?

--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages