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

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.

What we need is:
1/ 32-bit OS: IP is 32-bit in the sampling buffer
2/ 64-bit OS: IP is 64-bit in the sampling buffer

Because of 32-bit ABI tool running on 2/, the IP would have
to be defined as u64. But then it would be overkill on 1/.

The problem is in the user level header file for the sampling buffer.
We would need a data type that is 64-bit for IP if the host OS is 64-bit
(regardless of the ABI used by the tool, i.e., the compiler). And a data
type that is 32-bit on 32-bit OS. The problem is that there is no compiler
flag or header flag somewhere that could guide the compiler. In the case
of MIPS, we have defined a libpfm compile flags that indicates we want
the 64-bit OS definition when compiling for a 32-bit application.

--
-Stephane
-
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

  • Re: [patch] export percpu cpuacct cgroup stats
    ... I'm curious what compiler and CPU arch target are you using that cause ... compiler to spit out this warning message? ... On x86_64 u64 is unsigned ... long long and gcc v4.2.4 doesn't give such warning. ...
    (Linux-Kernel)
  • Re: [patch] export percpu cpuacct cgroup stats
    ... I'm curious what compiler and CPU arch target are you using that cause ... On x86_64 u64 is unsigned ... I tried it on IA64, and gcc version is 4.1.2. ...
    (Linux-Kernel)