[lttng-dev] Making 32-bit user-space events on a 64-bit Linux system

[Mathieu Desnoyers]

----- Original Message -----
> From: "Alexandre Montplaisir" <alexmonthy at voxpopuli.im>
> To: "Daniel Thibault" <Daniel.Thibault at drdc-rddc.gc.ca>, lttng-dev at lists.lttng.org
> Sent: Thursday, October 3, 2013 11:54:15 AM
> Subject: Re: [lttng-dev] Making 32-bit user-space events on a 64-bit Linux system
> 
> >> 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).

No, this is not it at all. 32-bit apps can generate 64-bit integers too, and double-precision floats.

The difference between 32 and 64-bit consumers mainly comes for atomic operations: on 64-bit, consumer and application can interact through atomic operations on 64-bit integers, which allow detection of free-running counter overflow much larger than with 32-bit counter.

Thanks,

Mathieu


  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
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com