Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tests/benchmarks/timing_info measurements are suddenly higher than previous values on nrf52_pca10040 #15202

Closed
arun1joshi opened this issue Apr 5, 2019 · 3 comments
Assignees
Labels
bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug

Comments

@arun1joshi
Copy link
Contributor

arun1joshi commented Apr 5, 2019

Describe the bug
tests/benchmarks/timing_info measurements are suddenly higher than previous values on nrf52_pca10040.

To Reproduce

Steps to reproduce the behavior:
run tests/benchmarks/timing_info

Expected behavior
No uptick in measurement

Impact
Its not blocking anything

Screenshots or console output

***** Booting Zephyr OS v1.14.0-rc3-99-g14db4eedff71 (delayed boot 1000ms) *****
starting test - Time Measurement
Timing Results: Clock Frequency: 64 MHz
Context switch                               : 372 cycles ,  5766 ns
Interrupt latency                            : 100 cycles ,  1550 ns
Tick overhead                                :   0 cycles ,     0 ns
Thread Creation                              :1400 cycles , 21700 ns
Thread cancel                                :3388 cycles , 52514 ns
Thread abort                                 :3732 cycles , 57846 ns
Thread Suspend                               :1116 cycles , 17298 ns
Thread Resume                                :1056 cycles , 16368 ns
Thread Yield                                 :1160 cycles , 17980 ns
Thread Sleep                                 :1964 cycles , 30442 ns
Heap Malloc                                  : 792 cycles , 12276 ns
Heap Free                                    : 864 cycles , 13392 ns
Semaphore Take with context switch           :2012 cycles , 31186 ns
Semaphore Give with context switch           :1492 cycles , 23126 ns
Semaphore Take without context switch        : 120 cycles ,  1860 ns
Semaphore Give without context switch        : 624 cycles ,  9672 ns
Mutex lock                                   : 624 cycles ,  9672 ns
Mutex unlock                                 : 736 cycles , 11408 ns
Message Queue Put with context switch        :1384 cycles , 21452 ns
Message Queue Put without context switch     : 304 cycles ,  4712 ns
Message Queue get with context switch        :1652 cycles , 25606 ns
Message Queue get without context switch     : 312 cycles ,  4836 ns
MailBox synchronous put                      :2252 cycles , 34906 ns
MailBox synchronous get                      :1656 cycles , 25668 ns
MailBox asynchronous put                     : 512 cycles ,  7936 ns
MailBox get without context switch           :1228 cycles , 19034 ns
Drop to user mode                            :1336 cycles , 20708 ns
User thread Creation                         :3184 cycles , 49352 ns
Syscall overhead                             : 228 cycles ,  3534 ns
Validation overhead k object init            : 240 cycles ,  3720 ns
Validation overhead k object permission      : 232 cycles ,  3596 ns
Timing Measurement  finished
PASS - main
===================================================================

Environment (please complete the following information):

  • OS: Fedora29
  • Toolchain: Zephyr SDK v.10.0
  • Commit SHA or Version used: 14db4ee

Additional context
Add any other context about the problem here.
I am comparing the values to the last result I have for a 12/mar/19 commit [af4ecea]

@arun1joshi arun1joshi added the bug The issue is a bug, or the PR is fixing a bug label Apr 5, 2019
@carlescufi
Copy link
Member

@pizi-nordic @nashif @arun1joshi could this be a regression with the performance of the compiler?

@nashif
Copy link
Member

nashif commented Apr 9, 2019

this can be a lot of things, I would like to see the data from a "good run" first.

@nashif nashif added the priority: low Low impact/importance bug label Apr 9, 2019
@nashif
Copy link
Member

nashif commented Mar 11, 2020

no update for a while, not sure this is a bug, numbers change all the time.

@nashif nashif closed this as completed Mar 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug
Projects
None yet
Development

No branches or pull requests

4 participants