mm/dump:add command to support dump memory usage of all pids by xiaoqizhan · Pull Request #18468 · apache/nuttx

xiaoqizhan · 2026-02-28T07:19:02Z

For the memdump command, when CONFIG_MM_BACKTRACE >= 0 is enabled, it currently only supports dumping all leaked memory nodes and memory usage for a specific PID. It does not support dumping memory usage of all processes in one go.
In some scenarios, it is necessary to dump memory usage of all processes at once. For example, when the memory pressure monitoring system detects that memory falls below a certain threshold, it needs to obtain the memory usage of all processes. Similarly, in some automation scripts, it is necessary to periodically collect memory data of each process for memory leak analysis.

Note: Please adhere to Contributing Guidelines.

Summary

This change extends the functionality of the memdump command to support dumping memory usage of all processes at once. Previously, when CONFIG_MM_BACKTRACE >= 0 was enabled, the memdump command only supported dumping leaked memory nodes and memory usage of a specific PID, but not all processes in one operation.
The enhancement addresses practical use cases such as:
Obtaining full process memory usage when the memory pressure monitoring system detects memory below a certain threshold;
Collecting periodic memory data of all processes in automation scripts for memory leak analysis.
New subcommands are added:
memdump a / memdump allpid: Dump memory usage of all processes;
memdump allpid [seqmin] [seqmax]: Dump memory usage of processes within the specified seq range.
This feature is only active when CONFIG_MM_BACKTRACE >= 0; it is not available if CONFIG_MM_BACKTRACE < 0.

Impact

User Impact
New subcommands (allpid/a) are added to the memdump command, which are fully backward-compatible (existing memdump functionalities for leaked nodes and specific PID remain unchanged);
Users need to ensure CONFIG_MM_BACKTRACE >= 0 (e.g., 0, 3,) to access the new features; the new commands are invisible when CONFIG_MM_BACKTRACE < 0.
Compatibility
No breaking changes to existing code or build process;
The new logic is wrapped under the existing CONFIG_MM_BACKTRACE macro, so no additional configuration dependencies are introduced.
Documentation
Relevant documentation (e.g., command usage docs) needs to be updated to include the new memdump subcommands and their usage constraints (macro dependency).

Testing

Build Configuration:
Test 1: CONFIG_MM_BACKTRACE = 0
Test 2: CONFIG_MM_BACKTRACE = 3
Test 3: CONFIG_MM_BACKTRACE = -1 (negative value for negative case verification)
Test Steps & Results

Positive Case (CONFIG_MM_BACKTRACE >= 0)
Step 1: Configure CONFIG_MM_BACKTRACE = 0 in the build config, compile and flash the firmware to the target board.
Step 2: Execute memdump a (alias for memdump allpid) on the target shell; verify the output format and content:
plaintext
pid: 853, used: 0, nused: 0
pid: 22, used: 104336, nused: 77
pid: 23, used: 340856, nused: 160
pid: 24, used: 0, nused: 0
Step 3: Execute memdump allpid 0 1000; verify processes with seq in 0-1000 range are output (consistent with the above format, filtered by seq range
Step 4: Repeat Step 1-3 with CONFIG_MM_BACKTRACE = 3; confirm the same output behavior (new commands work normally).
Negative Case (CONFIG_MM_BACKTRACE < 0)
Step 1: Configure CONFIG_MM_BACKTRACE = -1, recompile and flash firmware.
Step 2: Execute memdump a / memdump allpid on the target shell; verify the commands are not recognized (no response for new subcommands), and only original memdump functionalities are retained.
Regression Test
Verify existing memdump features (dump leaked memory nodes, specific PID memory usage) work as expected after the change, with no regression.
Test Logs (Key Snippets)
bash
运行

Log for CONFIG_MM_BACKTRACE=0 + memdump allpid

root@board:/# memdump allpid
pid: 22, used: 104336, nused: 77
pid: 23, used: 340856, nused: 160

Log for CONFIG_MM_BACKTRACE=0 + memdump allpid 0 1000

root@board:/# memdump allpid 0 1000
pid: 22, used: 0, nused: 0
pid: 23, used: 340856, nused: 160

For the memdump command, when CONFIG_MM_BACKTRACE >= 0 is enabled, it currently only supports dumping all leaked memory nodes and memory usage for a specific PID. It does not support dumping memory usage of all processes in one go. In some scenarios, it is necessary to dump memory usage of all processes at once. For example, when the memory pressure monitoring system detects that memory falls below a certain threshold, it needs to obtain the memory usage of all processes. Similarly, in some automation scripts, it is necessary to periodically collect memory data of each process for memory leak analysis. Signed-off-by: zhanxiaoqi <zhanxiaoqi@bytedance.com>

acassis

@xiaoqizhan thank you for extending the memdump, I noticed we don't have any Documentation about memdump, only dumpstack and similar. Could you please add a initial Documentation page about it (just basic info).

Or, if you want include more info, maybe include things like that response from @anjiahao1 about this issue: #9504 to make it more complete and helpful for developers.

acassis · 2026-02-28T13:28:03Z

mm/mm_heap/mm_memdump.c

+  unsigned long seqmin;
+  unsigned long seqmax;


Why not use uintptr_t instead of "unsigned long"? It should be more adaptable to different architectures and data types.

@acassis ,Thank you for your review and feedback. The parameters of the memdump command are passed down via the memdump_write method, with the relevant code in this method as follows:

struct mm_memdump_s dump =
{
PID_MM_ALLOC,
#if CONFIG_MM_BACKTRACE >= 0
0,
ULONG_MAX
#endif
};
The type of mm_memdump_s is struct malltask, whose definition is shown below:

struct malltask
{
pid_t pid; /* Process id /
#if CONFIG_MM_BACKTRACE >= 0
unsigned long seqmin; / The minimum sequence /
unsigned long seqmax; / The maximum sequence */
#endif
};
To maintain consistency with the previous data types, I also use unsigned long for seqmin and seqmax here.

Thank you @xiaoqizhan, so let's keep it for now, but I suggest fixing it later (in another PR) using "uintptr_t" to make it to adapt better for each arch case.

@acassis Thank you for your valuable suggestion. I will try to optimize it in another PR as you recommended.

include/malloc.h

xiaoxiang781216 · 2026-03-02T06:49:43Z

mm/mm_heap/mm_memdump.c

+      tcb_arg.heap = heap;
+      tcb_arg.seqmin = dump->seqmin;
+      tcb_arg.seqmax = dump->seqmax;
+      nxsched_foreach(memdump_tcb_handler, &tcb_arg);


why not reuse memdump_handler, the current approach has two loop(tcb + mem) which is very slower than one loop.

@xiaoxiang781216
Thank you for your review and feedback. If the memdump_handler method is used, it will further call memdump_allocnode, which dumps detailed information of each node (including call stacks and other logs), which does not meet the current requirements. Additionally, in my patch, it calls mm_foreach(heap, mallinfo_task_handler, &handle) to traverse all memory nodes of the heap and perform statistics, without recording or outputting any other extra information.
In terms of the number of loops: a total of 3 loops are required: nxsched_foreach traverses the corresponding pid, mm_foreach traverses mm_nregions of the corresponding heap, and then traverses memory nodes based on each region to execute the callback function for statistics. The implementations of memdump_handler and mallinfo_task_handler are basically similar.
In the native implementation, when using the memdump pid command, traversal is performed via mm_foreach(heap, memdump_handler, &priv), which also involves two loops: traversing mm_nregions of the corresponding heap, and then traversing memory nodes based on each region. To obtain the memory information for all PIDs, an additional loop level is required, so the total number of loops remains three.

ok, but why not pass dump to nxsched_foreach and remove memdump_tcb_arg_s.
BTW, it's better to integrate this feature to meminfo_read with an Kconfig(e.g. CONFIG_FS_PROCFS_MEMINFO_DETAIL) by extending procfs_meminfo_entry_s::mallinfo to procfs_meminfo_entry_s::mallinfo_task

wangchdo · 2026-03-03T14:45:27Z

mm/mm_heap/mm_memdump.c

 }

+#if CONFIG_MM_BACKTRACE >= 0
+struct memdump_tcb_arg_s


Please put the type definition in section:

/****************************************************************************

Private Types
****************************************************************************/

anchao · 2026-03-04T02:31:03Z

fs/procfs/fs_procfsmeminfo.c

        break;

 #if CONFIG_MM_BACKTRACE >= 0
+        case 'a':


Suggested change

case 'a':

case 'a':

anchao · 2026-03-04T02:32:09Z

include/malloc.h


 /* Special PID to query the info about alloc, free and mempool */

+#if CONFIG_MM_BACKTRACE >= 0


Suggested change

#if CONFIG_MM_BACKTRACE >= 0

remove, definition does not require adding macro check

anchao · 2026-03-04T02:32:54Z

mm/mm_heap/mm_memdump.c

 }

+#if CONFIG_MM_BACKTRACE >= 0
+struct memdump_tcb_arg_s


move to file begin and add Private Types chapter

anchao · 2026-03-04T02:34:42Z

mm/mm_heap/mm_memdump.c

+  task.seqmin = tcb_arg->seqmin;
+  task.seqmax = tcb_arg->seqmax;
+  info = mm_mallinfo_task(tcb_arg->heap, &task);
+  syslog(LOG_INFO, "pid:%5d, used:%10d, nused:%10d\n",


Suggested change

syslog(LOG_INFO, "pid:%5d, used:%10d, nused:%10d\n",

syslog(LOG_INFO, "PID: %5d, Used: %10d, NUsed: %10d\n",

anchao · 2026-03-04T02:38:08Z

mm/mm_heap/mm_memdump.c

+  task.seqmin = tcb_arg->seqmin;
+  task.seqmax = tcb_arg->seqmax;
+  info = mm_mallinfo_task(tcb_arg->heap, &task);
+  syslog(LOG_INFO, "pid:%5d, used:%10d, nused:%10d\n",


could we filter out PIDs that don't use any memory?

xiaoqizhan requested review from Donny9, xiaoxiang781216 and yamt as code owners February 28, 2026 07:19

github-actions bot added Area: File System File System issues Size: S The size of the change in this PR is small labels Feb 28, 2026

simbit18 requested review from acassis, anchao, linguini1, michallenc, raiden00pl and wangchdo February 28, 2026 07:31

acassis requested changes Feb 28, 2026

View reviewed changes

acassis reviewed Feb 28, 2026

View reviewed changes

xiaoqizhan requested a review from acassis March 2, 2026 01:59

xiaoxiang781216 reviewed Mar 2, 2026

View reviewed changes

xiaoqizhan requested a review from xiaoxiang781216 March 2, 2026 10:23

wangchdo reviewed Mar 3, 2026

View reviewed changes

anchao requested changes Mar 4, 2026

View reviewed changes

anchao reviewed Mar 4, 2026

View reviewed changes

acassis approved these changes Mar 4, 2026

View reviewed changes

jerpelea approved these changes Mar 4, 2026

View reviewed changes


		/* Special PID to query the info about alloc, free and mempool */

		#if CONFIG_MM_BACKTRACE >= 0

	syslog(LOG_INFO, "pid:%5d, used:%10d, nused:%10d\n",
	syslog(LOG_INFO, "PID: %5d, Used: %10d, NUsed: %10d\n",

Conversation

xiaoqizhan commented Feb 28, 2026

Summary

Impact

Testing

Log for CONFIG_MM_BACKTRACE=0 + memdump allpid

Log for CONFIG_MM_BACKTRACE=0 + memdump allpid 0 1000

Uh oh!

acassis left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anchao Mar 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

anchao Mar 4, 2026 •

edited

Loading