CODEWITHSUNDEEP
c++linuxperformanceclock
Pawel Faron
Pawel Faron

Reputation: 312

Code performance strick measurement

I’m creating performance framework tool for measuring individual message processing time in CentOS 7. I reserved one CPU for this task with isolcpus kernel option and I run it using taskset.

Ok, now the problem. I trying to measure the max processing time among several messages. The processing time is <= 1000ns, but when I run many iterations I get very high results (> 10000ns).

Here I created some simple code which does nothing interesting but shows the problem. Depending on the number of iterations i can get results like:

max: 84 min: 23 -> for 1000 iterations
max: 68540 min: 11 -> for 100000000 iterations

I'm trying to understand from where this difference came from? I tried to run this with real-time scheduling with highest priority. Is there some way to prevent that?

#include <iostream>
#include <limits>
#include <time.h>

const unsigned long long SEC = 1000L*1000L*1000L;

inline int64_t time_difference( const timespec &start,
                             const timespec &stop ) {
    return ( (stop.tv_sec * SEC - start.tv_sec * SEC) +
             (stop.tv_nsec - start.tv_nsec));
}
int main()
{
    timespec start, stop;
    int64_t max = 0, min = std::numeric_limits<int64_t>::max();

    for(int i = 0; i < 100000000; ++i){
        clock_gettime(CLOCK_REALTIME, &start);
        clock_gettime(CLOCK_REALTIME, &stop);
        int64_t time = time_difference(start, stop);
        max = std::max(max, time);
        min = std::min(min, time);
    }
    std::cout << "max: " << max << " min: " << min << std::endl;
}

Upvotes: 0

Views: 111

Answers (2)

BeeOnRope
BeeOnRope

Reputation: 64895

You can't really reduce jitter to zero even with isolcpus, since you still have at least the following:

1) Interrupts delivered to your CPU (you may be able to reduce this my messing with irq affinity - but probably not to zero).

2) Clock timer interrupts are still scheduled for your process and may do a variable amount of work on the kernel side.

3) The CPU itself may pause briefly for P-state or C-state transitions, or other reasons (e.g., to let voltage levels settle after turning on AVX circuitry, etc).

Upvotes: 2

Daniel Lemire
Daniel Lemire

Reputation: 3618

Let us check the documentation...

Isolation will be effected for userspace processes - kernel threads may still get scheduled on the isolcpus isolated CPUs.

So it seems that there is no guarantee of perfect isolation, at least not from the kernel.

Upvotes: 1

Related Questions