Decorated Operations for QorIQ P3/P4/P5 Processors - Freescale ...

Using Decorations in Software and Performance Results
the need for the final operation to be executed in the CPC, that is, “Fire and Forget.” They are therefore be
executed in one cycle or fewer 1 . The performance is comparably high relative to lock-based approaches
(see Section 3, “Using Decorations in Software and Performance Results”).
3 Using Decorations in Software and Performance
Results
Decorated operations are typically implemented with macros to simplify usage; alternatively, they could
overload basic add/subtract functions for applicable programming language such as C++. In the following
benchmark case, the operation is implemented in bare-metal directly on the P4080 without an underlying
operating system. Seven of the eight cores are running bare-metal, whereas the last core is running Linux
to simplify the boot process. However, the operating system configuration and at what level the decorated
operations are implemented are not important, because they are executed on the same privilege level and
have the same characteristics for the core as normal load/store operations. Tests are made both in
single-core as well as multicore configurations.
There are three required areas for data accessed by a decorated operation. First, a pointer to the data must
be defined, as follows:
volatile int32_t *decorated_counter = NULL;
In the program code, allocate the data and set the value to a default state, in this case zero, as follows:
decorated_counter=(int32_t *) stats_memalign(CACHE_LINE_SIZE,
sizeof(int32_t));
*decorated_counter = 0;
Finally, the code makes use of the data by executing a decorated operation, as follows:
decorated_notify_inc_32(decorated_counter);
The typical use-case for decorated operations is to update a data structure that occurs relatively seldomly,
approximately less than every hundred cycle. In this case, an update is executed in a single cycle, which
is the same as it is for private data. For a lock-based update, the programmer gets roughly 35 cycles in the
ideal single-core case. These tests were measured by reading the clock cycle timer, running the test,
reading cycle timer again, and then removing a measured overhead for reading the timers. The overhead
is at a stable 4 clock cycles:
atb_start = mfspr(SPR_ATBL); //start timer
decorated_notify_inc_32(decorated_counter);
atb_stop = mfspr(SPR_ATBL); //stop timer
Because locks use an SoC-wide atomic function, they are affected by other locks. For example, when one
core runs the code (above) and the other cores wait at a different lock, the cycle count increases from
roughly 35 cycles to about 200 cycles. When all cores operate on the same lock, there is additional cycle
count increase. A synthetic use-case that is not typically found in real applications, but has general interest
due to the extensive load it puts on the system, is to run a long loop of updates. This also allows for
1. The e500mc core is superscalar and can load and retire up to two instructions per cycle under certain conditions.
Decorated Operations for QorIQ P3/P4/P5 Processors, Rev. A
6 Freescale Confidential Proprietary Freescale Semiconductor
Preliminary—Subject to Change Without Notice