[lttng-dev] Making 32-bit user-space events on a 64-bit Linux system
Alexandre Montplaisir
alexmonthy at voxpopuli.im
Thu Oct 3 11:54:15 EDT 2013
>> The Debian/Ubuntu packages for liblttng-ust and liburcu are multiarch-enabled, so you can install the :i386 and :amd64 versions in
>> parallel. That way they will be tracked by the package manager, and won't "linger around".
> Except that the Ubuntu LTTng packages are hopelessly behind right now. I wanted to do everything with the 2.3.0 release.
The packages from the official repo are often behind, yes. But we have
an Ubuntu PPA which follows the stable releases:
https://launchpad.net/~lttng/+archive/ppa
It's updated daily with the contents of the stable-* git branches.
> On a different note, why does LTTng have 32- and 64-bit consumers anyway? The only possible difference between a 32-bit tracer and a
> 64-bit tracer is that the latter could generate event record fields that are 64-bit longs and floats, while the former cannot (but will never
> have to, since the application it is tracing won't have such beasts anyway). So the 64-bit consumer should be backward compatible with the
> 32-bit consumer, because it deals with a super-set of the 32-bit consumer requirements. If this were the only difference, LTTng would not
> need a separate 32-bit consumer daemon. Is there some sort of context-switching overhead associated with a 64-bit daemon accessing a
> buffer that exists in a 32-bit process context? The performance gain would justify the existence of a 32-bit consumer, I suppose.
The consumer shares memory space with the traced process, so they have
to use the same ABI. If they talked only through let's say a pipe, that
wouldn't be necessary, but performance would indeed be much worse.
Cheers,
Alex
More information about the lttng-dev
mailing list