-
Notifications
You must be signed in to change notification settings - Fork 7.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
[Heap Trace Standalone] improvements to formatting, code, comments (IDFGH-8699) #10141
[Heap Trace Standalone] improvements to formatting, code, comments (IDFGH-8699) #10141
Conversation
1c63dd3
to
27677d1
Compare
a4ed195
to
c742eec
Compare
@igrr Would love to get all of these changes merged. (pending review) I have a separate PR to ~1000x the perf of standalone Leaks mode, which I'd like to rebase. With the perf change (doubly linked list & simple hash table), standalone leaks mode is fast enough to be enabled 24/7 during development, so all living memory allocations can be printed when low ram is hit. Very useful! |
8a3d62f
to
5982cd4
Compare
dff315d
to
ff24df2
Compare
@igrr, bump. It's a pretty simple change, despite the largish-diff. |
ff24df2
to
01b5f84
Compare
@SoucheSouche, I noticed you are the reviewer on my other Heap Trace PR. Please let me know your thoughts / if there is anything you'd like me to change. |
Hi @chipweinberger, I will have a look at your PR very shortly. Sorry for not answering earlier. |
Hi @chipweinberger, thank you for this contribution! I had a look at your PR and everything looks great. However, I have a few notes.
The points above lead to the removal of the |
Thanks for the review. I think we could keep During development of new chips, breifly disable the KConfig, until Or perhaps, we could move All of this being said, I will remove |
01b5f84
to
9afc386
Compare
I think it is best to discuss this outside of this PR as you mentioned as we should address your other PR before deciding on Your latest changes look good to me. I will create the merge request today and keep you updated. Thanks again for your contribution! |
I think the problem is just generally that a lower-level component (heap) depends on the higher-level component (spi_flash). This is something we are trying to avoid. There might be a way to let |
Ah, got it. Keeping good hierarchy is important. Yes, an optional callback registration seems like a simple solution! |
Hi @chipweinberger, |
nice! that seems like a good change! |
Hi @chipweinberger, your feature was merged successfully! Sorry it took a little longer than expected but I had to create tests for the added functions. |
great! appreciate your work in getting this in! |
This looks like a bug to me. What will happen when the count is 0?
I suppose it gets casted back to |
@chipweinberger , this is a good point. In both 32 and 64 bits architectures, |
Original PR: #10127
Explicitly allow SPI ram for standalone heap tracing, and improve its usage.
total_isr_skipped
, which gets incremented if psram records buffer is lockedheap_trace_dump_internal_ram()
. I usually run out of internal ram, and only want to see internal ram.heap_trace_dump_psram()
, for completenessheap_trace_summary()
so that users can access alll heap tracing information.records_t
struct, for clarityhigh_water_mark
to the records buffer, to make it easier for users to choose a buffer sizeheap_trace_dump
for clarity, and print "PSRAM" v.s. "Internal" for each allocationtotal_frees
would not get incremented when records count is 0