-
Notifications
You must be signed in to change notification settings - Fork 3k
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
NVStore tests: Tune memory consumption; stop threads greafully #7127
Conversation
@@ -378,6 +377,27 @@ static void nvstore_basic_functionality_test() | |||
delete[] nvstore_testing_buf_get; | |||
} | |||
|
|||
static void calc_thread_stack_size(int &num_threads, uint32_t min_size, uint32_t max_size, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a comment to the function about the parameters. There two in/out parameters and the idea of the function is good but not trivial. Beside that looks OK to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, I was reading the definition how the test gets num threads and stack size (I knew it would be via &), plus what heap_get returns if heap stats are not enabled (memset to 0, thus the check in reserved_size) - these were not obvious to me , neither then what while does in the below on line 391
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
document the calc_thread_stack size helper function
8a37d8d
to
85f0934
Compare
Explanations added. |
Ok with me |
85f0934
to
f0362c3
Compare
@maciejbocianski @mprse @fkjagodzinski Please review changes in features/nvstore/TESTS/nvstore/functionality/main.cpp (this seems like it might be useful for other tests as well) |
I noticed that this change cause the test is still failing on NRF52 nad ARCH_PRO when run with CI config (develop + MBED_TRAP_ERRORS_ENABLED, MBED_ALL_STATS_ENABLED, MBED_HEAP_STATS_ENABLED, MBED_STACK_STATS_ENABLED)
|
|
||
// Check if we can allocate enough stack size (per thread) for the current number of threads | ||
while (num_threads) { | ||
stack_size = (heap_stats.reserved_size - heap_stats.current_size) / num_threads; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could happen that we utilize whole remaining heap memory for threads, we should leave some margin (e.g. 10% of reserved_size or 1kB)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood. Are you saying this as a general note or specifically for this test? Reason I ask is that both min and max values in this test (768/2048) take these spares into account. However, I may create a more general infrastructure for this, as I get more and more low memory boards that fail on these kind of tests, so may take this into account.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's general note. How does it take these spares into account?
e.g. If we have 8kB free heap memory , then whole 8kB will be utilized for threads, am I right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, now I understand you comment. Thought the spares you mentioned were to be used by the threads themselves and not by the main thread. Yes, you have a point here.
@davidsaada Would you happen to have test results that show that this PR should pass tests with the CI flags enabled on the NRF52? |
975bf02
to
6d4d0dd
Compare
Made a change to this PR (also updated PR description), adding a graceful stop to the multi-thread test instead of thread termination, as killing threads causes a few issues if it happens during low level actions (like flash programming in the NRF52 board). |
It's OK now, following PR changes. Test built with heap & stack stats enabled. Here's the test output:
|
@davidsaada Fyi, you can use ``` ``` to encapsulate CLI output to make it easier to read :) |
You are right of course, and I usually do that. Maybe all this text made me lose my grip... |
Hi
|
Exporter Build : SUCCESSBuild number : 2113 |
Test : FAILUREBuild number : 2252 |
- Tune thread stack size in nvstore test using heap stats - Stop threads gracefully instead of killing them (in multi-thread test)
6d4d0dd
to
1b5b839
Compare
Pushed a few small changes following failed test. Believe it should be OK now (also tested on failed board). |
Interesting. Since it looks like there were a good chunk of changes with that last commit, I'm going to ask for a re-review. @dannybenor @maciejbocianski @0xc0170 @marcuschangarm Would y'all mind looking at the commit again? |
Folks - any chance to get a review? This PR fixes a few issues. |
/morph build |
Build : SUCCESSBuild number : 2564 Triggering tests/morph test |
Test : SUCCESSBuild number : 2318 |
Exporter Build : SUCCESSBuild number : 2208 |
…t_alloc NVStore tests: Tune memory consumption; stop threads greafully
Description
Revise NVStore tests:
Pull request type