I have some debug code which traverses the thread list using chRegFirstThread() and chRegNextThread() to calculate percentage CPU usage for each thread. This works fine in 20.3.4.
The same routine moved to 21.11.3, with appropriate changes to variables, gets values of zero for the timings tp->stats.cumulative, and also the context switching count tp->stats.n. All other threads yield what look to be reasonable results.
The address of the idle thread as give by the travering pointer matches that from chSysGetIdleThreadX(); thread priority is 1, and the name is correct.
My assumption is that the idle thread is treated the same as all others, in that context switches go through chSysSwitch(ntp, otp), which calls __stats_ctxswc(thread_t *ntp, thread_t *otp) - or is the idle thread different in some key way?
Idle thread stats handling changed in 21.11?
- Giovanni
- Site Admin
- Posts: 14565
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1112 times
- Been thanked: 937 times
- Contact:
Re: Idle thread stats handling changed in 21.11?
Hi,
It is a normal thread, it is just created in a different way.
A quick test seems to agree with your finding, numbers are off, I will look into this.
Giovanni
It is a normal thread, it is just created in a different way.
A quick test seems to agree with your finding, numbers are off, I will look into this.
Giovanni
- Giovanni
- Site Admin
- Posts: 14565
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1112 times
- Been thanked: 937 times
- Contact:
Re: Idle thread stats handling changed in 21.11?
Hi,
I committed tentative fixes for 2 distinct problems:
1) ARM Cortex-M (alternate) port had a bug that caused the "0" in the idle thread (but also made other threads values invalid).
2) A bug in the RT kernel caused a very large value for the main thread.
Changes committed to trunk and 21.11.x stable.
Giovanni
I committed tentative fixes for 2 distinct problems:
1) ARM Cortex-M (alternate) port had a bug that caused the "0" in the idle thread (but also made other threads values invalid).
2) A bug in the RT kernel caused a very large value for the main thread.
Changes committed to trunk and 21.11.x stable.
Giovanni
Re: Idle thread stats handling changed in 21.11?
That's a lot better.
The per-thread statistics now make a lot more sense.
The context switch counts also look accurate - for example I get 262546 as the value from currcore->kernel_stats.n_ctxswc, and 260576 from having added up tp->stats.n across all threads; no locking and code execution times mean that a difference is expected, and pretty stable around 1960-1970 counts.
However, not convinced on the kernel stats; they are giving some odd values which I've not properly investigated yet.
Are the following times already included in the thread times (Looks as if they are):
currcore->kernel_stats.m_crit_thd.cumulative;
currcore->kernel_stats.m_crit_isr.cumulative;
At present, critical section time is improbably low (approaching zero). Number of interrupts is improbably low (<50). Total ISR time is excessively high (much greater than total execution time)
The per-thread statistics now make a lot more sense.
The context switch counts also look accurate - for example I get 262546 as the value from currcore->kernel_stats.n_ctxswc, and 260576 from having added up tp->stats.n across all threads; no locking and code execution times mean that a difference is expected, and pretty stable around 1960-1970 counts.
However, not convinced on the kernel stats; they are giving some odd values which I've not properly investigated yet.
Are the following times already included in the thread times (Looks as if they are):
currcore->kernel_stats.m_crit_thd.cumulative;
currcore->kernel_stats.m_crit_isr.cumulative;
At present, critical section time is improbably low (approaching zero). Number of interrupts is improbably low (<50). Total ISR time is excessively high (much greater than total execution time)
- Giovanni
- Site Admin
- Posts: 14565
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1112 times
- Been thanked: 937 times
- Contact:
Re: Idle thread stats handling changed in 21.11?
Hi,
Number of interrupts can be low in tick-less mode, there is no periodic tick.
Critical sections must be read carefully, if there is a blocking API inside a critical section then the "unlock" is performed by the woken thread, the code path can be not obvious.
Said that, let me know if you notice anomalies.
Giovanni
Number of interrupts can be low in tick-less mode, there is no periodic tick.
Critical sections must be read carefully, if there is a blocking API inside a critical section then the "unlock" is performed by the woken thread, the code path can be not obvious.
Said that, let me know if you notice anomalies.
Giovanni
Re: Idle thread stats handling changed in 21.11?
Looked into this a bit more, and concluded that the strange values I'm getting for kernel stats are somehow down to a mix of uint32_t and uint64_t variables. Possibly a contribution from chprintf(); certainly I've noted that unsigned long variables are saved into a signed long internally.
Re: Idle thread stats handling changed in 21.11?
Hi Bob; still keeping going, thanks. Although not much to do with Chibi the past couple of years. Existing projects all stable, and ST's shortages discouraged new projects. Might have used the RP2040 instead if they'd made it easy to port the libraries, but probably that ship has sailed unless I find an application that needs PIO.
Anyway, got the residual bits sorted; not so much a problem with chprintf() (apart from the signed/unsigned long detail) as matching variable types with the formatting strings as for printf() (although IIRC gcc now picks up errors if you use printf()). Life was simple when Chibi only needed to support 32-bit integers...
Anyway, got the residual bits sorted; not so much a problem with chprintf() (apart from the signed/unsigned long detail) as matching variable types with the formatting strings as for printf() (although IIRC gcc now picks up errors if you use printf()). Life was simple when Chibi only needed to support 32-bit integers...
Who is online
Users browsing this forum: No registered users and 10 guests