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
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
David Gibson wrote:
> On Sat, Feb 11, 2006 at 02:33:54PM -0800, Stephane Eranian wrote:
[...]
>> 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?
Either, or both, depending on the measurement settings.
I live in a 64-bit world, so my take on this issue would be to expose
the PC as a uint64_t, always. There is already so much overhead in the
default per-sample header that I wouldn't worry about it.
Now 64 bit might not always be enough. E.g., on PA-RISC. But _I_ do
not care much about Linux on PA.
Eric
--
Eric Gouriou [email protected]
David,
On Sun, Feb 12, 2006 at 04:03:44PM -0800, Eric Gouriou wrote:
> David Gibson wrote:
> >On Sat, Feb 11, 2006 at 02:33:54PM -0800, Stephane Eranian wrote:
> [...]
> >>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?
>
> Either, or both, depending on the measurement settings.
>
> I live in a 64-bit world, so my take on this issue would be to expose
> the PC as a uint64_t, always. There is already so much overhead in the
> default per-sample header that I wouldn't worry about it.
>
Eric is right, on many architectures, incl. PPC64 I am sure, you can easily
configure a counter to measure at any priv levels including at the kernel level.
As such a 32-bt monitoring tool could see 64-bit generated samples. Similarly,
I don't think it would be unreasonable to have a 32-bit tool monitor 64-bit
applications.
The question is whether hardcoding the IP to always be u64 is a valid choice.
Eric's comment about overhead is based on the current default sampling format
which systematically adds a fixed size header to each sample. That header
contains the IP. So adding 4 bytes to this header is not a big deal.
However, because we can define virtual PMDs that map to software resources, it
is likely that the default format will evolve to allow an application to specify
everything it needs for each sample. For instance, you can have a PMD
that maps to the current PID, another one that maps to the interrupt IP. Then
you can chose to include those into the sample and you would nto need a fixed size
header anymore.
--
-Stephane