Re: Question about performance and tracepoint structure

Re: Question about performance and tracepoint structure

[Mathieu Desnoyers]

* Amit Margalit (AMITM@il.ibm.com) wrote:
> Hi,
> 
> This may be a bit of a noob question, and I think I read about this 
> somewhere but I can't find it now.
> 
> When I declare a tracepoint that's made up of a uint8_t, followed by a 
> uint16_t followed by a uint32_t, for example, there are 2 ways to handle 
> this - packed or unpacked.
> 
> If we're doing packed, then we have to include some code that does the 
> packing properly as alignment issues can creep up. This code causes us to 
> incur some CPU cycles at that point.

it's not code. it's just that cpus are slightly slower at doing
unaligned accesses than aligned accesses.

> If we're doing unpacked, then we incur some cycles on passing the event to 
> the sessiond, and sessiond suffers by having to write down some extra 
> bytes, which is less efficient.

yes

> 
> Either way, I think it means I can gain some minor performance 
> improvements if I reorder my tracepoint arguments to a more efficient 
> order - alignment-wise.

Well, yes. You will want to reorder the tracepoint "TP_FIELDS" so the
largest fields come first, followed by the smaller fields.

The order of arguments (TP_ARGS) does not matter.

Thanks,

Mathieu

> 
> Am I barking up the wrong tree here?
> 
> Thanks,
> 
> Amit Margalit
> IBM XIV - Storage Reinvented
> XIV-NAS Development Team
> Tel. 03-689-7774
> Fax. 03-689-7230
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev


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

Re: Question about performance and tracepoint structure

[Amit Margalit]

[-- Attachment #1.1: Type: text/plain, Size: 2100 bytes --]

Thanks, that helps a lot.

By the way - how do strings fit in this? Is it best that they are last? 
Maybe best they are first being the largest?

Amit Margalit
IBM XIV - Storage Reinvented
XIV-NAS Development Team
Tel. 03-689-7774
Fax. 03-689-7230



From:   Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To:     Amit Margalit/Israel/IBM@IBMIL
Cc:     lttng-dev@lists.lttng.org
Date:   07/10/2013 08:25 PM
Subject:        Re: [lttng-dev] Question about performance and tracepoint 
structure



* Amit Margalit (AMITM@il.ibm.com) wrote:
> Hi,
> 
> This may be a bit of a noob question, and I think I read about this 
> somewhere but I can't find it now.
> 
> When I declare a tracepoint that's made up of a uint8_t, followed by a 
> uint16_t followed by a uint32_t, for example, there are 2 ways to handle 

> this - packed or unpacked.
> 
> If we're doing packed, then we have to include some code that does the 
> packing properly as alignment issues can creep up. This code causes us 
to 
> incur some CPU cycles at that point.

it's not code. it's just that cpus are slightly slower at doing
unaligned accesses than aligned accesses.

> If we're doing unpacked, then we incur some cycles on passing the event 
to 
> the sessiond, and sessiond suffers by having to write down some extra 
> bytes, which is less efficient.

yes

> 
> Either way, I think it means I can gain some minor performance 
> improvements if I reorder my tracepoint arguments to a more efficient 
> order - alignment-wise.

Well, yes. You will want to reorder the tracepoint "TP_FIELDS" so the
largest fields come first, followed by the smaller fields.

The order of arguments (TP_ARGS) does not matter.

Thanks,

Mathieu

> 
> Am I barking up the wrong tree here?
> 
> Thanks,
> 
> Amit Margalit
> IBM XIV - Storage Reinvented
> XIV-NAS Development Team
> Tel. 03-689-7774
> Fax. 03-689-7230
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev


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



[-- Attachment #1.2: Type: text/html, Size: 3726 bytes --]

[-- Attachment #2: Type: text/plain, Size: 155 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: Question about performance and tracepoint structure

[Mathieu Desnoyers]

* Amit Margalit (AMITM@il.ibm.com) wrote:
> Thanks, that helps a lot.
> 
> By the way - how do strings fit in this? Is it best that they are last? 
> Maybe best they are first being the largest?

last. Those are really an array of characters, terminated by '\0',
therefore the alignment is that of a character (1-byte).

Thanks,

Mathieu

> 
> Amit Margalit
> IBM XIV - Storage Reinvented
> XIV-NAS Development Team
> Tel. 03-689-7774
> Fax. 03-689-7230
> 
> 
> 
> From:   Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> To:     Amit Margalit/Israel/IBM@IBMIL
> Cc:     lttng-dev@lists.lttng.org
> Date:   07/10/2013 08:25 PM
> Subject:        Re: [lttng-dev] Question about performance and tracepoint 
> structure
> 
> 
> 
> * Amit Margalit (AMITM@il.ibm.com) wrote:
> > Hi,
> > 
> > This may be a bit of a noob question, and I think I read about this 
> > somewhere but I can't find it now.
> > 
> > When I declare a tracepoint that's made up of a uint8_t, followed by a 
> > uint16_t followed by a uint32_t, for example, there are 2 ways to handle 
> 
> > this - packed or unpacked.
> > 
> > If we're doing packed, then we have to include some code that does the 
> > packing properly as alignment issues can creep up. This code causes us 
> to 
> > incur some CPU cycles at that point.
> 
> it's not code. it's just that cpus are slightly slower at doing
> unaligned accesses than aligned accesses.
> 
> > If we're doing unpacked, then we incur some cycles on passing the event 
> to 
> > the sessiond, and sessiond suffers by having to write down some extra 
> > bytes, which is less efficient.
> 
> yes
> 
> > 
> > Either way, I think it means I can gain some minor performance 
> > improvements if I reorder my tracepoint arguments to a more efficient 
> > order - alignment-wise.
> 
> Well, yes. You will want to reorder the tracepoint "TP_FIELDS" so the
> largest fields come first, followed by the smaller fields.
> 
> The order of arguments (TP_ARGS) does not matter.
> 
> Thanks,
> 
> Mathieu
> 
> > 
> > Am I barking up the wrong tree here?
> > 
> > Thanks,
> > 
> > Amit Margalit
> > IBM XIV - Storage Reinvented
> > XIV-NAS Development Team
> > Tel. 03-689-7774
> > Fax. 03-689-7230
> > _______________________________________________
> > lttng-dev mailing list
> > lttng-dev@lists.lttng.org
> > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 
> 
> -- 
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
> 
> 

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

Question about performance and tracepoint structure

[Amit Margalit]

[-- Attachment #1.1: Type: text/plain, Size: 957 bytes --]

Hi,

This may be a bit of a noob question, and I think I read about this 
somewhere but I can't find it now.

When I declare a tracepoint that's made up of a uint8_t, followed by a 
uint16_t followed by a uint32_t, for example, there are 2 ways to handle 
this - packed or unpacked.

If we're doing packed, then we have to include some code that does the 
packing properly as alignment issues can creep up. This code causes us to 
incur some CPU cycles at that point.

If we're doing unpacked, then we incur some cycles on passing the event to 
the sessiond, and sessiond suffers by having to write down some extra 
bytes, which is less efficient.

Either way, I think it means I can gain some minor performance 
improvements if I reorder my tracepoint arguments to a more efficient 
order - alignment-wise.

Am I barking up the wrong tree here?

Thanks,

Amit Margalit
IBM XIV - Storage Reinvented
XIV-NAS Development Team
Tel. 03-689-7774
Fax. 03-689-7230

[-- Attachment #1.2: Type: text/html, Size: 1623 bytes --]

[-- Attachment #2: Type: text/plain, Size: 155 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev