How did you verify it's working and which platform did you use?

I tested on cortex-m3 (stm32f2). I assumed it worked before. It must be a leftover of the recent xtimer works.

• converted ps runtime_ticks to float
• used _xtimer_now64() instead of xtimer_now()
• used unsigned long long for ticks counting variables
• fixed examples/default Makefile

• addressed @gebart comments
• add a test app to ensure this code is compiled by Murdock

@vincent-d I think you address[ed] all comments, please rebase and squash accordingly; and we give Murdock a try 😉

squashed

Why is runtime_ticks a double in the first place?

I think I understand now! printf wants a double when using %f. So either we cast or we use a double.

or we don't use float nor double, see my follow up PR #7048. Your PR here already does a lot: use uint64_t and xtimer_now64 and adds a tests!

@smlng I agree, but Murdock complains. I propose to move runtime_ticks back to double and finish the job in #7048.

that's exactly what I meant: revert to double and refine that using #7048

Fixed and squashed directly

@smlng do you want to re-ACK ? Otherwise I think we can go.

as @kaspar030 did not object, ACK and GO

Did you just merge 64bit calculations into the scheduler?! I thought adding the "core" flag would lead to more thorough review.

Context switch performance goes down from 26k/sec to 18k/sec with this PR, with enabled schecstatistics...

Context switch performance goes down from 26k/sec to 18k/sec with this PR

So guys, what do we do about it. Ignore it, revert, fix?

@kaspar030 please share your performance test application. And clarify what did you compare:

• without and with MODULE_SCHEDSTATISTICS of this PR
• or using MODULE_SCHEDSTATISTICS before (32Bit) or with this PR (64Bit)

I used this: https://github.com/kaspar030/RIOT/tree/add_bench_msg/tests/bench_msg

The test sends messages in a loop from the main thread to a second thread, which just receives them in a loop. After one second, it stops and outputs how many messages could be sent.

I compared the results of master afgter merging this PR without MODULE_SCHEDSTATISTICS, then the module added to USEMODULE, then again with the module, but 6d5b955 reverted, all on samr21-xpro.

The results (Test complete. n=...) were ~42k, ~18k and ~26k.

(The benchmark result is very unstable on native, probably due to CPUs slowly scaling up. So to get meaningful results, run it on real hardware.)

The module was broken, anyway.

We can go back to 32bits knowing that it would work only for the first 32bits ticks. This is a reasonable limitation I guess.

I can confirm @kaspar030 findings that switching performance drops from 60% to 40% using schedstatistics with 64Bit instead of 32Bit compared to performance without stats. Besides other issue with the module, we already that know gathering stats will influence overall performance. Question remains: how to proceed, and is another drop that severe? What about impact of xtimer performance on this one - which can be improved as well as, see #7053?

Btw. I get a hardfault on pba-d-01-kw2x when using the stats module, regardless of the changes in this PR - even reverting them completely doesn't help.

What about impact of xtimer performance on this one - which can be improved as well as, see #7053?

Good point, but only matters if xtimer is run with a timer on a different clock domain than the default.

We can go back to 32bits knowing that it would work only for the first 32bits ticks. This is a reasonable limitation I guess.

Would it be possible to count using a 32bit variable on context switch, but record any overflows?
e.g.,

tmp = _tick_count;
stats->_tick_count += now-laststart;
if (_tick_count < tmp) stats->overflows++;

... and handle the 64bit math on printing?
That way we'd move the reasonable limitation to "if a thread runs for more than 71 minutes without context switch or interrupt, output is incorrect".

edit All variables being 32bit.

can't we use _xtimer_now_internal which gives the overflows, instead of keep track of them here again?

can't we use _xtimer_now_internal which gives the overflows, instead of keep track of them here again?

wouldn't you need overflow detection per thread? I am not sure how to map from one value (_xtimer_now_internal) onto the runtime of several threads..

ah, right (in a way) - we may need to combine _xtimer_now_internal usage with @kaspar030 proposal, because for the latter: consecutive overflows would be missed, or not?