* [PATCH] tools/mm: Introduce a tool to handle entries in allocinfo @ 2025-01-06 11:21 Hao Ge 2025-01-06 21:11 ` Suren Baghdasaryan 2025-01-09 0:19 ` kernel test robot 0 siblings, 2 replies; 14+ messages in thread From: Hao Ge @ 2025-01-06 11:21 UTC (permalink / raw) To: akpm, surenb, kent.overstreet; +Cc: linux-kernel, linux-mm, hao.ge, Hao Ge From: Hao Ge <gehao@kylinos.cn> Some users always say that the information provided by /proc/allocinfo is too extensive or bulky. However, from allocinfo's own perspective, it is not at fault as it needs to provide comprehensive information. Users can then select the information that is useful to them based on their own needs. For commonly used scenarios, we can develop a tool to facilitate users in filtering and utilizing relevant information from allocinfo. Currently, there is only one filtering feature available, which is to filter out entries where the 'bytes' field is 0 (since it is often used to understand the current memory allocation status, as previously mentioned by David Wang, who noticed that 2/3 of the lines have an accumulative counter of 0, indicating no memory activities,it will fill up the entire screen,by using the "-s" parameter, a lot of unnecessary information for this scenario can be filtered out.) In subsequent phases, we will continue to add more features to this tool, with the goal of making it convenient for most people to use the memory allocation profiling tool. Signed-off-by: Hao Ge <gehao@kylinos.cn> --- MAINTAINERS | 1 + tools/mm/Makefile | 4 +- tools/mm/allocinfo_tool.c | 150 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 153 insertions(+), 2 deletions(-) create mode 100644 tools/mm/allocinfo_tool.c diff --git a/MAINTAINERS b/MAINTAINERS index 910305c11e8a..cfc3f9f0c046 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -15000,6 +15000,7 @@ F: Documentation/mm/allocation-profiling.rst F: include/linux/alloc_tag.h F: include/linux/pgalloc_tag.h F: lib/alloc_tag.c +F: tools/mm/allocinfo_tool.c MEMORY CONTROLLER DRIVERS M: Krzysztof Kozlowski <krzk@kernel.org> diff --git a/tools/mm/Makefile b/tools/mm/Makefile index f5725b5c23aa..f669d534a82b 100644 --- a/tools/mm/Makefile +++ b/tools/mm/Makefile @@ -3,7 +3,7 @@ # include ../scripts/Makefile.include -BUILD_TARGETS=page-types slabinfo page_owner_sort thp_swap_allocator_test +BUILD_TARGETS=page-types slabinfo page_owner_sort thp_swap_allocator_test allocinfo_tool INSTALL_TARGETS = $(BUILD_TARGETS) thpmaps LIB_DIR = ../lib/api @@ -23,7 +23,7 @@ $(LIBS): $(CC) $(CFLAGS) -o $@ $< $(LDFLAGS) clean: - $(RM) page-types slabinfo page_owner_sort thp_swap_allocator_test + $(RM) page-types slabinfo page_owner_sort thp_swap_allocator_test allocinfo_tool make -C $(LIB_DIR) clean sbindir ?= /usr/sbin diff --git a/tools/mm/allocinfo_tool.c b/tools/mm/allocinfo_tool.c new file mode 100644 index 000000000000..817f46d07a50 --- /dev/null +++ b/tools/mm/allocinfo_tool.c @@ -0,0 +1,150 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * allocinfo_tool: Tool to parse allocinfo + * + * Authors: Hao Ge <hao.ge@linux.dev> + * + * Compile with: + * gcc -o allocinfo_tool allocinfo_tool.c + */ + +#include<stdio.h> +#include<stdlib.h> +#include<sys/stat.h> +#include <string.h> +#include <getopt.h> + +#define ALLOCINFO_FILE "/proc/allocinfo" +#define BUF_SIZE 1024 +#define NAME_MAX_LENTH 64 + +struct alloc_tag_counters { + signed long long bytes; + unsigned long long calls; +}; + +struct codetag { + unsigned int lineno; + char modname[NAME_MAX_LENTH]; + char function[NAME_MAX_LENTH]; + char filename[NAME_MAX_LENTH]; +}; + +struct alloc_info { + struct alloc_tag_counters counters; + struct codetag tag; + int has_modname; +}; + +static int arg_opt; + +enum OPT_BIT { + SKIP_ZERO = 1 << 0, +}; + +void usage(void) +{ + printf("Usage: ./allocinfo_tool [OPTIONS]\n" + "-s\t\t\tskip bytes for 0 allocinfo entries\n" + ); +} + +int parse_alloc_info(char *line, struct alloc_info *info) +{ + if (sscanf(line, "%12lli %8llu %[^:]:%d [%[^]]] func:%s", + &info->counters.bytes, &info->counters.calls, + info->tag.filename, &info->tag.lineno, + info->tag.modname, info->tag.function) == 6){ + info->has_modname = 1; + return 1; + }; + + if (sscanf(line, "%12llu %8llu %[^:]:%u func:%s", + &info->counters.bytes, &info->counters.calls, + info->tag.filename, &info->tag.lineno, + info->tag.function) == 5){ + info->has_modname = 0; + return 1; + } + + return 0; +} + +int read_alloc_info(void) +{ + FILE *file = fopen(ALLOCINFO_FILE, "r"); + + if (!file) { + perror("Failed to open /proc/allocinfo"); + return EXIT_FAILURE; + } + + int line = 0, i = 0; + char *buffer = malloc(BUF_SIZE); + struct alloc_info *info; + + while (fgets(buffer, BUF_SIZE, file)) { + + /* + * allocinfo - version: 1.0 + * # <size> <calls> <tag info> + */ + if (line < 2) { + printf("%s", buffer); + line++; + continue; + } + + info = realloc(info, sizeof(struct alloc_info) * (i + 1)); + + if (parse_alloc_info(buffer, info + i) == 0) { + printf("Mismatch with the format of /proc/allocinfo"); + return 0; + } + + if ((arg_opt & SKIP_ZERO) && (info[i].counters.bytes == 0)) + continue; + + printf("%12lli %8llu ", info[i].counters.bytes, info[i].counters.calls); + + if (info[i].has_modname) + printf("%s:%u [%s] func:%s", + info[i].tag.filename, info[i].tag.lineno, + info[i].tag.modname, info[i].tag.function); + else + printf("%s:%u func:%s", + info[i].tag.filename, info[i].tag.lineno, + info[i].tag.function); + printf(" "); + printf("\n"); + i++; + } + + free(info); + free(buffer); + fclose(file); +} + +int main(int argc, char *argv[]) +{ + + int opt; + struct option longopts[] = { + { "s", 0, NULL, 1}, + { 0, 0, 0, 0}, + }; + + while ((opt = getopt_long(argc, argv, "s", longopts, NULL)) != -1) { + switch (opt) { + case 's': + arg_opt = arg_opt | SKIP_ZERO; + break; + default: + usage(); + exit(1); + } + } + + read_alloc_info(); + +} -- 2.25.1 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] tools/mm: Introduce a tool to handle entries in allocinfo 2025-01-06 11:21 [PATCH] tools/mm: Introduce a tool to handle entries in allocinfo Hao Ge @ 2025-01-06 21:11 ` Suren Baghdasaryan 2025-01-07 15:11 ` Alessio Balsini 2025-01-11 14:31 ` David Wang 2025-01-09 0:19 ` kernel test robot 1 sibling, 2 replies; 14+ messages in thread From: Suren Baghdasaryan @ 2025-01-06 21:11 UTC (permalink / raw) To: Hao Ge Cc: akpm, kent.overstreet, linux-kernel, linux-mm, Hao Ge, Alessio Balsini, Pasha Tatashin, Sourav Panda, David Wang On Mon, Jan 6, 2025 at 3:22 AM Hao Ge <hao.ge@linux.dev> wrote: > > From: Hao Ge <gehao@kylinos.cn> > > Some users always say that the information provided by /proc/allocinfo > is too extensive or bulky. > > However, from allocinfo's own perspective, it is not at fault as it > needs to provide comprehensive information. Users can then select the > information that is useful to them based on their own needs. > > For commonly used scenarios, we can develop a tool to facilitate users in > filtering and utilizing relevant information from allocinfo. > > Currently, there is only one filtering feature available, which is to > filter out entries where the 'bytes' field is 0 (since it is often used > to understand the current memory allocation status, as previously > mentioned by David Wang, who noticed that 2/3 of the lines have an > accumulative counter of 0, indicating no memory activities,it will fill > up the entire screen,by using the "-s" parameter, a lot of unnecessary > information for this scenario can be filtered out.) > > In subsequent phases, we will continue to add more features to this tool, > with the goal of making it convenient for most people to use the memory > allocation profiling tool. CC'ing Alessio along with Pasha and Sourav who were interested in such a tool. Hi Hao, Thanks for the tool! Actually Alessio just developed a tool called alloctop (similar to slabtop) which I think will do what you want and more. It supports sorting, filtering, continuous update, etc. It's written in Rust and we are planning to upstream it once we finish testing and evaluating it on Android. Please take a look and see if it fits your usecase. Please also note that this tool has been implemented just last week, so hot off the press and might have some early bugs. Thanks, Suren. [1] https://cs.android.com/android/platform/superproject/main/+/main:system/memory/libmeminfo/tools/alloctop/src/ > > Signed-off-by: Hao Ge <gehao@kylinos.cn> > --- > MAINTAINERS | 1 + > tools/mm/Makefile | 4 +- > tools/mm/allocinfo_tool.c | 150 ++++++++++++++++++++++++++++++++++++++ > 3 files changed, 153 insertions(+), 2 deletions(-) > create mode 100644 tools/mm/allocinfo_tool.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 910305c11e8a..cfc3f9f0c046 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -15000,6 +15000,7 @@ F: Documentation/mm/allocation-profiling.rst > F: include/linux/alloc_tag.h > F: include/linux/pgalloc_tag.h > F: lib/alloc_tag.c > +F: tools/mm/allocinfo_tool.c > > MEMORY CONTROLLER DRIVERS > M: Krzysztof Kozlowski <krzk@kernel.org> > diff --git a/tools/mm/Makefile b/tools/mm/Makefile > index f5725b5c23aa..f669d534a82b 100644 > --- a/tools/mm/Makefile > +++ b/tools/mm/Makefile > @@ -3,7 +3,7 @@ > # > include ../scripts/Makefile.include > > -BUILD_TARGETS=page-types slabinfo page_owner_sort thp_swap_allocator_test > +BUILD_TARGETS=page-types slabinfo page_owner_sort thp_swap_allocator_test allocinfo_tool > INSTALL_TARGETS = $(BUILD_TARGETS) thpmaps > > LIB_DIR = ../lib/api > @@ -23,7 +23,7 @@ $(LIBS): > $(CC) $(CFLAGS) -o $@ $< $(LDFLAGS) > > clean: > - $(RM) page-types slabinfo page_owner_sort thp_swap_allocator_test > + $(RM) page-types slabinfo page_owner_sort thp_swap_allocator_test allocinfo_tool > make -C $(LIB_DIR) clean > > sbindir ?= /usr/sbin > diff --git a/tools/mm/allocinfo_tool.c b/tools/mm/allocinfo_tool.c > new file mode 100644 > index 000000000000..817f46d07a50 > --- /dev/null > +++ b/tools/mm/allocinfo_tool.c > @@ -0,0 +1,150 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * allocinfo_tool: Tool to parse allocinfo > + * > + * Authors: Hao Ge <hao.ge@linux.dev> > + * > + * Compile with: > + * gcc -o allocinfo_tool allocinfo_tool.c > + */ > + > +#include<stdio.h> > +#include<stdlib.h> > +#include<sys/stat.h> > +#include <string.h> > +#include <getopt.h> > + > +#define ALLOCINFO_FILE "/proc/allocinfo" > +#define BUF_SIZE 1024 > +#define NAME_MAX_LENTH 64 > + > +struct alloc_tag_counters { > + signed long long bytes; > + unsigned long long calls; > +}; > + > +struct codetag { > + unsigned int lineno; > + char modname[NAME_MAX_LENTH]; > + char function[NAME_MAX_LENTH]; > + char filename[NAME_MAX_LENTH]; > +}; > + > +struct alloc_info { > + struct alloc_tag_counters counters; > + struct codetag tag; > + int has_modname; > +}; > + > +static int arg_opt; > + > +enum OPT_BIT { > + SKIP_ZERO = 1 << 0, > +}; > + > +void usage(void) > +{ > + printf("Usage: ./allocinfo_tool [OPTIONS]\n" > + "-s\t\t\tskip bytes for 0 allocinfo entries\n" > + ); > +} > + > +int parse_alloc_info(char *line, struct alloc_info *info) > +{ > + if (sscanf(line, "%12lli %8llu %[^:]:%d [%[^]]] func:%s", > + &info->counters.bytes, &info->counters.calls, > + info->tag.filename, &info->tag.lineno, > + info->tag.modname, info->tag.function) == 6){ > + info->has_modname = 1; > + return 1; > + }; > + > + if (sscanf(line, "%12llu %8llu %[^:]:%u func:%s", > + &info->counters.bytes, &info->counters.calls, > + info->tag.filename, &info->tag.lineno, > + info->tag.function) == 5){ > + info->has_modname = 0; > + return 1; > + } > + > + return 0; > +} > + > +int read_alloc_info(void) > +{ > + FILE *file = fopen(ALLOCINFO_FILE, "r"); > + > + if (!file) { > + perror("Failed to open /proc/allocinfo"); > + return EXIT_FAILURE; > + } > + > + int line = 0, i = 0; > + char *buffer = malloc(BUF_SIZE); > + struct alloc_info *info; > + > + while (fgets(buffer, BUF_SIZE, file)) { > + > + /* > + * allocinfo - version: 1.0 > + * # <size> <calls> <tag info> > + */ > + if (line < 2) { > + printf("%s", buffer); > + line++; > + continue; > + } > + > + info = realloc(info, sizeof(struct alloc_info) * (i + 1)); > + > + if (parse_alloc_info(buffer, info + i) == 0) { > + printf("Mismatch with the format of /proc/allocinfo"); > + return 0; > + } > + > + if ((arg_opt & SKIP_ZERO) && (info[i].counters.bytes == 0)) > + continue; > + > + printf("%12lli %8llu ", info[i].counters.bytes, info[i].counters.calls); > + > + if (info[i].has_modname) > + printf("%s:%u [%s] func:%s", > + info[i].tag.filename, info[i].tag.lineno, > + info[i].tag.modname, info[i].tag.function); > + else > + printf("%s:%u func:%s", > + info[i].tag.filename, info[i].tag.lineno, > + info[i].tag.function); > + printf(" "); > + printf("\n"); > + i++; > + } > + > + free(info); > + free(buffer); > + fclose(file); > +} > + > +int main(int argc, char *argv[]) > +{ > + > + int opt; > + struct option longopts[] = { > + { "s", 0, NULL, 1}, > + { 0, 0, 0, 0}, > + }; > + > + while ((opt = getopt_long(argc, argv, "s", longopts, NULL)) != -1) { > + switch (opt) { > + case 's': > + arg_opt = arg_opt | SKIP_ZERO; > + break; > + default: > + usage(); > + exit(1); > + } > + } > + > + read_alloc_info(); > + > +} > -- > 2.25.1 > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] tools/mm: Introduce a tool to handle entries in allocinfo 2025-01-06 21:11 ` Suren Baghdasaryan @ 2025-01-07 15:11 ` Alessio Balsini 2025-01-08 1:16 ` Hao Ge 2025-01-11 14:31 ` David Wang 1 sibling, 1 reply; 14+ messages in thread From: Alessio Balsini @ 2025-01-07 15:11 UTC (permalink / raw) To: Suren Baghdasaryan Cc: Hao Ge, akpm, kent.overstreet, linux-kernel, linux-mm, Hao Ge, Alessio Balsini, Pasha Tatashin, Sourav Panda, David Wang Thank you Suren for looping me in and Hao for the tool! As Suren mentioned, we recently developed `alloctop` for the same reason as yours: easy and fast manipulation of `/proc/allocinfo` instead of having long chains of piped sorts, greps, awks... `alloctop` takes `slabtop` as a reference for command line parameters and output format. It currently supports sorting and filtering by minimum allocation size, as well as some kind of aggregation based on tag (similar to what `du` does). As Suren mentioned, the tool is currently being tested on Android, but we would be happy to collaborate on adding new features and making it part of tools/mm. Thanks, Alessio On Mon, Jan 6, 2025 at 9:12 PM Suren Baghdasaryan <surenb@google.com> wrote: > > On Mon, Jan 6, 2025 at 3:22 AM Hao Ge <hao.ge@linux.dev> wrote: > > > > From: Hao Ge <gehao@kylinos.cn> > > > > Some users always say that the information provided by /proc/allocinfo > > is too extensive or bulky. > > > > However, from allocinfo's own perspective, it is not at fault as it > > needs to provide comprehensive information. Users can then select the > > information that is useful to them based on their own needs. > > > > For commonly used scenarios, we can develop a tool to facilitate users in > > filtering and utilizing relevant information from allocinfo. > > > > Currently, there is only one filtering feature available, which is to > > filter out entries where the 'bytes' field is 0 (since it is often used > > to understand the current memory allocation status, as previously > > mentioned by David Wang, who noticed that 2/3 of the lines have an > > accumulative counter of 0, indicating no memory activities,it will fill > > up the entire screen,by using the "-s" parameter, a lot of unnecessary > > information for this scenario can be filtered out.) > > > > In subsequent phases, we will continue to add more features to this tool, > > with the goal of making it convenient for most people to use the memory > > allocation profiling tool. > > CC'ing Alessio along with Pasha and Sourav who were interested in such a tool. > > Hi Hao, > Thanks for the tool! Actually Alessio just developed a tool called > alloctop (similar to slabtop) which I think will do what you want and > more. It supports sorting, filtering, continuous update, etc. It's > written in Rust and we are planning to upstream it once we finish > testing and evaluating it on Android. Please take a look and see if it > fits your usecase. Please also note that this tool has been > implemented just last week, so hot off the press and might have some > early bugs. > Thanks, > Suren. > > [1] https://cs.android.com/android/platform/superproject/main/+/main:system/memory/libmeminfo/tools/alloctop/src/ > > > > > Signed-off-by: Hao Ge <gehao@kylinos.cn> > > --- > > MAINTAINERS | 1 + > > tools/mm/Makefile | 4 +- > > tools/mm/allocinfo_tool.c | 150 ++++++++++++++++++++++++++++++++++++++ > > 3 files changed, 153 insertions(+), 2 deletions(-) > > create mode 100644 tools/mm/allocinfo_tool.c > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 910305c11e8a..cfc3f9f0c046 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -15000,6 +15000,7 @@ F: Documentation/mm/allocation-profiling.rst > > F: include/linux/alloc_tag.h > > F: include/linux/pgalloc_tag.h > > F: lib/alloc_tag.c > > +F: tools/mm/allocinfo_tool.c > > > > MEMORY CONTROLLER DRIVERS > > M: Krzysztof Kozlowski <krzk@kernel.org> > > diff --git a/tools/mm/Makefile b/tools/mm/Makefile > > index f5725b5c23aa..f669d534a82b 100644 > > --- a/tools/mm/Makefile > > +++ b/tools/mm/Makefile > > @@ -3,7 +3,7 @@ > > # > > include ../scripts/Makefile.include > > > > -BUILD_TARGETS=page-types slabinfo page_owner_sort thp_swap_allocator_test > > +BUILD_TARGETS=page-types slabinfo page_owner_sort thp_swap_allocator_test allocinfo_tool > > INSTALL_TARGETS = $(BUILD_TARGETS) thpmaps > > > > LIB_DIR = ../lib/api > > @@ -23,7 +23,7 @@ $(LIBS): > > $(CC) $(CFLAGS) -o $@ $< $(LDFLAGS) > > > > clean: > > - $(RM) page-types slabinfo page_owner_sort thp_swap_allocator_test > > + $(RM) page-types slabinfo page_owner_sort thp_swap_allocator_test allocinfo_tool > > make -C $(LIB_DIR) clean > > > > sbindir ?= /usr/sbin > > diff --git a/tools/mm/allocinfo_tool.c b/tools/mm/allocinfo_tool.c > > new file mode 100644 > > index 000000000000..817f46d07a50 > > --- /dev/null > > +++ b/tools/mm/allocinfo_tool.c > > @@ -0,0 +1,150 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * allocinfo_tool: Tool to parse allocinfo > > + * > > + * Authors: Hao Ge <hao.ge@linux.dev> > > + * > > + * Compile with: > > + * gcc -o allocinfo_tool allocinfo_tool.c > > + */ > > + > > +#include<stdio.h> > > +#include<stdlib.h> > > +#include<sys/stat.h> > > +#include <string.h> > > +#include <getopt.h> > > + > > +#define ALLOCINFO_FILE "/proc/allocinfo" > > +#define BUF_SIZE 1024 > > +#define NAME_MAX_LENTH 64 > > + > > +struct alloc_tag_counters { > > + signed long long bytes; > > + unsigned long long calls; > > +}; > > + > > +struct codetag { > > + unsigned int lineno; > > + char modname[NAME_MAX_LENTH]; > > + char function[NAME_MAX_LENTH]; > > + char filename[NAME_MAX_LENTH]; > > +}; > > + > > +struct alloc_info { > > + struct alloc_tag_counters counters; > > + struct codetag tag; > > + int has_modname; > > +}; > > + > > +static int arg_opt; > > + > > +enum OPT_BIT { > > + SKIP_ZERO = 1 << 0, > > +}; > > + > > +void usage(void) > > +{ > > + printf("Usage: ./allocinfo_tool [OPTIONS]\n" > > + "-s\t\t\tskip bytes for 0 allocinfo entries\n" > > + ); > > +} > > + > > +int parse_alloc_info(char *line, struct alloc_info *info) > > +{ > > + if (sscanf(line, "%12lli %8llu %[^:]:%d [%[^]]] func:%s", > > + &info->counters.bytes, &info->counters.calls, > > + info->tag.filename, &info->tag.lineno, > > + info->tag.modname, info->tag.function) == 6){ > > + info->has_modname = 1; > > + return 1; > > + }; > > + > > + if (sscanf(line, "%12llu %8llu %[^:]:%u func:%s", > > + &info->counters.bytes, &info->counters.calls, > > + info->tag.filename, &info->tag.lineno, > > + info->tag.function) == 5){ > > + info->has_modname = 0; > > + return 1; > > + } > > + > > + return 0; > > +} > > + > > +int read_alloc_info(void) > > +{ > > + FILE *file = fopen(ALLOCINFO_FILE, "r"); > > + > > + if (!file) { > > + perror("Failed to open /proc/allocinfo"); > > + return EXIT_FAILURE; > > + } > > + > > + int line = 0, i = 0; > > + char *buffer = malloc(BUF_SIZE); > > + struct alloc_info *info; > > + > > + while (fgets(buffer, BUF_SIZE, file)) { > > + > > + /* > > + * allocinfo - version: 1.0 > > + * # <size> <calls> <tag info> > > + */ > > + if (line < 2) { > > + printf("%s", buffer); > > + line++; > > + continue; > > + } > > + > > + info = realloc(info, sizeof(struct alloc_info) * (i + 1)); > > + > > + if (parse_alloc_info(buffer, info + i) == 0) { > > + printf("Mismatch with the format of /proc/allocinfo"); > > + return 0; > > + } > > + > > + if ((arg_opt & SKIP_ZERO) && (info[i].counters.bytes == 0)) > > + continue; > > + > > + printf("%12lli %8llu ", info[i].counters.bytes, info[i].counters.calls); > > + > > + if (info[i].has_modname) > > + printf("%s:%u [%s] func:%s", > > + info[i].tag.filename, info[i].tag.lineno, > > + info[i].tag.modname, info[i].tag.function); > > + else > > + printf("%s:%u func:%s", > > + info[i].tag.filename, info[i].tag.lineno, > > + info[i].tag.function); > > + printf(" "); > > + printf("\n"); > > + i++; > > + } > > + > > + free(info); > > + free(buffer); > > + fclose(file); > > +} > > + > > +int main(int argc, char *argv[]) > > +{ > > + > > + int opt; > > + struct option longopts[] = { > > + { "s", 0, NULL, 1}, > > + { 0, 0, 0, 0}, > > + }; > > + > > + while ((opt = getopt_long(argc, argv, "s", longopts, NULL)) != -1) { > > + switch (opt) { > > + case 's': > > + arg_opt = arg_opt | SKIP_ZERO; > > + break; > > + default: > > + usage(); > > + exit(1); > > + } > > + } > > + > > + read_alloc_info(); > > + > > +} > > -- > > 2.25.1 > > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] tools/mm: Introduce a tool to handle entries in allocinfo 2025-01-07 15:11 ` Alessio Balsini @ 2025-01-08 1:16 ` Hao Ge 0 siblings, 0 replies; 14+ messages in thread From: Hao Ge @ 2025-01-08 1:16 UTC (permalink / raw) To: Alessio Balsini, Suren Baghdasaryan Cc: akpm, kent.overstreet, linux-kernel, linux-mm, Hao Ge, Alessio Balsini, Pasha Tatashin, Sourav Panda, David Wang [-- Attachment #1: Type: text/plain, Size: 9603 bytes --] Hi Suren and Alessio Thanks for your information. On 2025/1/7 23:11, Alessio Balsini wrote: > Thank you Suren for looping me in and Hao for the tool! > > As Suren mentioned, we recently developed `alloctop` for the same reason as > yours: easy and fast manipulation of `/proc/allocinfo` instead of having long > chains of piped sorts, greps, awks... > `alloctop` takes `slabtop` as a reference for command line parameters and > output format. > It currently supports sorting and filtering by minimum allocation size, as well > as some kind of aggregation based on tag (similar to what `du` does). Yes, I originally intended to gradually add such functionalities as well as those discovered during subsequent usage. > As Suren mentioned, the tool is currently being tested on Android, but we would > be happy to collaborate on adding new features and making it part of tools/mm. I'm also happy to do this. I salute everyone who has put in the effort for this. Make this tool increasingly user-friendly. Thanks Best Regards Hao > > Thanks, > Alessio > > On Mon, Jan 6, 2025 at 9:12 PM Suren Baghdasaryan<surenb@google.com> wrote: >> On Mon, Jan 6, 2025 at 3:22 AM Hao Ge<hao.ge@linux.dev> wrote: >>> From: Hao Ge<gehao@kylinos.cn> >>> >>> Some users always say that the information provided by /proc/allocinfo >>> is too extensive or bulky. >>> >>> However, from allocinfo's own perspective, it is not at fault as it >>> needs to provide comprehensive information. Users can then select the >>> information that is useful to them based on their own needs. >>> >>> For commonly used scenarios, we can develop a tool to facilitate users in >>> filtering and utilizing relevant information from allocinfo. >>> >>> Currently, there is only one filtering feature available, which is to >>> filter out entries where the 'bytes' field is 0 (since it is often used >>> to understand the current memory allocation status, as previously >>> mentioned by David Wang, who noticed that 2/3 of the lines have an >>> accumulative counter of 0, indicating no memory activities,it will fill >>> up the entire screen,by using the "-s" parameter, a lot of unnecessary >>> information for this scenario can be filtered out.) >>> >>> In subsequent phases, we will continue to add more features to this tool, >>> with the goal of making it convenient for most people to use the memory >>> allocation profiling tool. >> CC'ing Alessio along with Pasha and Sourav who were interested in such a tool. >> >> Hi Hao, >> Thanks for the tool! Actually Alessio just developed a tool called >> alloctop (similar to slabtop) which I think will do what you want and >> more. It supports sorting, filtering, continuous update, etc. It's >> written in Rust and we are planning to upstream it once we finish >> testing and evaluating it on Android. Please take a look and see if it >> fits your usecase. Please also note that this tool has been >> implemented just last week, so hot off the press and might have some >> early bugs. >> Thanks, >> Suren. >> >> [1]https://cs.android.com/android/platform/superproject/main/+/main:system/memory/libmeminfo/tools/alloctop/src/ >> >>> Signed-off-by: Hao Ge<gehao@kylinos.cn> >>> --- >>> MAINTAINERS | 1 + >>> tools/mm/Makefile | 4 +- >>> tools/mm/allocinfo_tool.c | 150 ++++++++++++++++++++++++++++++++++++++ >>> 3 files changed, 153 insertions(+), 2 deletions(-) >>> create mode 100644 tools/mm/allocinfo_tool.c >>> >>> diff --git a/MAINTAINERS b/MAINTAINERS >>> index 910305c11e8a..cfc3f9f0c046 100644 >>> --- a/MAINTAINERS >>> +++ b/MAINTAINERS >>> @@ -15000,6 +15000,7 @@ F: Documentation/mm/allocation-profiling.rst >>> F: include/linux/alloc_tag.h >>> F: include/linux/pgalloc_tag.h >>> F: lib/alloc_tag.c >>> +F: tools/mm/allocinfo_tool.c >>> >>> MEMORY CONTROLLER DRIVERS >>> M: Krzysztof Kozlowski<krzk@kernel.org> >>> diff --git a/tools/mm/Makefile b/tools/mm/Makefile >>> index f5725b5c23aa..f669d534a82b 100644 >>> --- a/tools/mm/Makefile >>> +++ b/tools/mm/Makefile >>> @@ -3,7 +3,7 @@ >>> # >>> include ../scripts/Makefile.include >>> >>> -BUILD_TARGETS=page-types slabinfo page_owner_sort thp_swap_allocator_test >>> +BUILD_TARGETS=page-types slabinfo page_owner_sort thp_swap_allocator_test allocinfo_tool >>> INSTALL_TARGETS = $(BUILD_TARGETS) thpmaps >>> >>> LIB_DIR = ../lib/api >>> @@ -23,7 +23,7 @@ $(LIBS): >>> $(CC) $(CFLAGS) -o $@ $< $(LDFLAGS) >>> >>> clean: >>> - $(RM) page-types slabinfo page_owner_sort thp_swap_allocator_test >>> + $(RM) page-types slabinfo page_owner_sort thp_swap_allocator_test allocinfo_tool >>> make -C $(LIB_DIR) clean >>> >>> sbindir ?= /usr/sbin >>> diff --git a/tools/mm/allocinfo_tool.c b/tools/mm/allocinfo_tool.c >>> new file mode 100644 >>> index 000000000000..817f46d07a50 >>> --- /dev/null >>> +++ b/tools/mm/allocinfo_tool.c >>> @@ -0,0 +1,150 @@ >>> +// SPDX-License-Identifier: GPL-2.0 >>> +/* >>> + * allocinfo_tool: Tool to parse allocinfo >>> + * >>> + * Authors: Hao Ge<hao.ge@linux.dev> >>> + * >>> + * Compile with: >>> + * gcc -o allocinfo_tool allocinfo_tool.c >>> + */ >>> + >>> +#include<stdio.h> >>> +#include<stdlib.h> >>> +#include<sys/stat.h> >>> +#include <string.h> >>> +#include <getopt.h> >>> + >>> +#define ALLOCINFO_FILE "/proc/allocinfo" >>> +#define BUF_SIZE 1024 >>> +#define NAME_MAX_LENTH 64 >>> + >>> +struct alloc_tag_counters { >>> + signed long long bytes; >>> + unsigned long long calls; >>> +}; >>> + >>> +struct codetag { >>> + unsigned int lineno; >>> + char modname[NAME_MAX_LENTH]; >>> + char function[NAME_MAX_LENTH]; >>> + char filename[NAME_MAX_LENTH]; >>> +}; >>> + >>> +struct alloc_info { >>> + struct alloc_tag_counters counters; >>> + struct codetag tag; >>> + int has_modname; >>> +}; >>> + >>> +static int arg_opt; >>> + >>> +enum OPT_BIT { >>> + SKIP_ZERO = 1 << 0, >>> +}; >>> + >>> +void usage(void) >>> +{ >>> + printf("Usage: ./allocinfo_tool [OPTIONS]\n" >>> + "-s\t\t\tskip bytes for 0 allocinfo entries\n" >>> + ); >>> +} >>> + >>> +int parse_alloc_info(char *line, struct alloc_info *info) >>> +{ >>> + if (sscanf(line, "%12lli %8llu %[^:]:%d [%[^]]] func:%s", >>> + &info->counters.bytes, &info->counters.calls, >>> + info->tag.filename, &info->tag.lineno, >>> + info->tag.modname, info->tag.function) == 6){ >>> + info->has_modname = 1; >>> + return 1; >>> + }; >>> + >>> + if (sscanf(line, "%12llu %8llu %[^:]:%u func:%s", >>> + &info->counters.bytes, &info->counters.calls, >>> + info->tag.filename, &info->tag.lineno, >>> + info->tag.function) == 5){ >>> + info->has_modname = 0; >>> + return 1; >>> + } >>> + >>> + return 0; >>> +} >>> + >>> +int read_alloc_info(void) >>> +{ >>> + FILE *file = fopen(ALLOCINFO_FILE, "r"); >>> + >>> + if (!file) { >>> + perror("Failed to open /proc/allocinfo"); >>> + return EXIT_FAILURE; >>> + } >>> + >>> + int line = 0, i = 0; >>> + char *buffer = malloc(BUF_SIZE); >>> + struct alloc_info *info; >>> + >>> + while (fgets(buffer, BUF_SIZE, file)) { >>> + >>> + /* >>> + * allocinfo - version: 1.0 >>> + * # <size> <calls> <tag info> >>> + */ >>> + if (line < 2) { >>> + printf("%s", buffer); >>> + line++; >>> + continue; >>> + } >>> + >>> + info = realloc(info, sizeof(struct alloc_info) * (i + 1)); >>> + >>> + if (parse_alloc_info(buffer, info + i) == 0) { >>> + printf("Mismatch with the format of /proc/allocinfo"); >>> + return 0; >>> + } >>> + >>> + if ((arg_opt & SKIP_ZERO) && (info[i].counters.bytes == 0)) >>> + continue; >>> + >>> + printf("%12lli %8llu ", info[i].counters.bytes, info[i].counters.calls); >>> + >>> + if (info[i].has_modname) >>> + printf("%s:%u [%s] func:%s", >>> + info[i].tag.filename, info[i].tag.lineno, >>> + info[i].tag.modname, info[i].tag.function); >>> + else >>> + printf("%s:%u func:%s", >>> + info[i].tag.filename, info[i].tag.lineno, >>> + info[i].tag.function); >>> + printf(" "); >>> + printf("\n"); >>> + i++; >>> + } >>> + >>> + free(info); >>> + free(buffer); >>> + fclose(file); >>> +} >>> + >>> +int main(int argc, char *argv[]) >>> +{ >>> + >>> + int opt; >>> + struct option longopts[] = { >>> + { "s", 0, NULL, 1}, >>> + { 0, 0, 0, 0}, >>> + }; >>> + >>> + while ((opt = getopt_long(argc, argv, "s", longopts, NULL)) != -1) { >>> + switch (opt) { >>> + case 's': >>> + arg_opt = arg_opt | SKIP_ZERO; >>> + break; >>> + default: >>> + usage(); >>> + exit(1); >>> + } >>> + } >>> + >>> + read_alloc_info(); >>> + >>> +} >>> -- >>> 2.25.1 >>> [-- Attachment #2: Type: text/html, Size: 17117 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] tools/mm: Introduce a tool to handle entries in allocinfo 2025-01-06 21:11 ` Suren Baghdasaryan 2025-01-07 15:11 ` Alessio Balsini @ 2025-01-11 14:31 ` David Wang 2025-01-12 4:41 ` David Wang 2025-01-13 21:47 ` [PATCH] tools/mm: Introduce a tool to handle entries in allocinfo Suren Baghdasaryan 1 sibling, 2 replies; 14+ messages in thread From: David Wang @ 2025-01-11 14:31 UTC (permalink / raw) To: Suren Baghdasaryan, kent.overstreet Cc: Hao Ge, akpm, kent.overstreet, linux-kernel, linux-mm, Hao Ge, Alessio Balsini, Pasha Tatashin, Sourav Panda Hi, I have using this feature for a long while, and I believe this memory alloc profiling feature is quite powerful. But, I have been wondering how to use this data, specifically: how anomaly could be detected, what pattern should be defined as anomaly? So far, I have tools collecting those data (via prometheus), make basic analysis, i.e. top-k, group-by or rate. Those analysis help me understand my system, but I cannot tell whether it is abnormal or not. And sometimes I would just read through /proc/allocinfo, trying to pickup something. (Sometimes get lucky, actually only once, find the underflow problem weeks ago.) A tool would be more helpful if it can identify anomalies, and we can add more pattern as develop along. A pattern may be hard to define, especially when it involves context. For example, I happened to notice following strange things recently: 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc 1025 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc 1025 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 1025 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc 1025 <----- B 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 210 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 210 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 210 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 210 <----- A Code A 2230 sdd->sd = alloc_percpu(struct sched_domain *); 2231 if (!sdd->sd) 2232 return -ENOMEM; 2233 Code B 2246 for_each_cpu(j, cpu_map) { ... 2251 2252 sd = kzalloc_node(sizeof(struct sched_domain) + cpumask_size(), 2253 GFP_KERNEL, cpu_to_node(j)); 2254 if (!sd) 2255 return -ENOMEM; 2256 2257 *per_cpu_ptr(sdd->sd, j) = sd; The address of memory alloced by 'Code B', is stored in memory "Code A', the allocation counter for 'Code A' is *0*, while 'Code B' is not *0*. Something odd happens here, either it is expected and some ownership changes happened somewhere , or it is a leak, or it is an accounting problem. If a tool can help identify this kind of pattern, that would be great!~ Any suggestions about how to proceed with the memory problem of kernel/sched/topology.c mentioneded above?, or is it a problem at all? Thanks David At 2025-01-07 05:11:47, "Suren Baghdasaryan" <surenb@google.com> wrote: >On Mon, Jan 6, 2025 at 3:22 AM Hao Ge <hao.ge@linux.dev> wrote: >> >> From: Hao Ge <gehao@kylinos.cn> >> >> Some users always say that the information provided by /proc/allocinfo >> is too extensive or bulky. >> > >CC'ing Alessio along with Pasha and Sourav who were interested in such a tool. > >Hi Hao, >Thanks for the tool! Actually Alessio just developed a tool called >alloctop (similar to slabtop) which I think will do what you want and >more. It supports sorting, filtering, continuous update, etc. It's >written in Rust and we are planning to upstream it once we finish >testing and evaluating it on Android. Please take a look and see if it >fits your usecase. Please also note that this tool has been >implemented just last week, so hot off the press and might have some >early bugs. >Thanks, >Suren. > >[1] https://cs.android.com/android/platform/superproject/main/+/main:system/memory/libmeminfo/tools/alloctop/src/ > >> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] tools/mm: Introduce a tool to handle entries in allocinfo 2025-01-11 14:31 ` David Wang @ 2025-01-12 4:41 ` David Wang 2025-01-13 8:03 ` memory alloc profiling seems not work properly during bootup? David Wang 2025-01-13 21:47 ` [PATCH] tools/mm: Introduce a tool to handle entries in allocinfo Suren Baghdasaryan 1 sibling, 1 reply; 14+ messages in thread From: David Wang @ 2025-01-12 4:41 UTC (permalink / raw) To: Suren Baghdasaryan, kent.overstreet Cc: Hao Ge, akpm, linux-kernel, linux-mm, Hao Ge, Alessio Balsini, Pasha Tatashin, Sourav Panda At 2025-01-11 22:31:36, "David Wang" <00107082@163.com> wrote: >Hi, > >I have using this feature for a long while, and I believe this memory alloc profiling feature >is quite powerful. > >But, I have been wondering how to use this data, specifically: >how anomaly could be detected, what pattern should be defined as anomaly? > >So far, I have tools collecting those data (via prometheus), make basic analysis, i.e. top-k, group-by or rate. >Those analysis help me understand my system, but I cannot tell whether it is abnormal or not. > >And sometimes I would just read through /proc/allocinfo, trying to pickup something. >(Sometimes get lucky, actually only once, find the underflow problem weeks ago.) > >A tool would be more helpful if it can identify anomalies, and we can add more pattern as develop along. > >A pattern may be hard to define, especially when it involves context. For example, >I happened to notice following strange things recently: > > 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc 1025 > 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc 1025 > 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 1025 > 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc 1025 <----- B > 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 210 > 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 210 > 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 210 > 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 210 <----- A >Code A >2230 sdd->sd = alloc_percpu(struct sched_domain *); >2231 if (!sdd->sd) >2232 return -ENOMEM; >2233 > >Code B >2246 for_each_cpu(j, cpu_map) { > ... > >2251 >2252 sd = kzalloc_node(sizeof(struct sched_domain) + cpumask_size(), >2253 GFP_KERNEL, cpu_to_node(j)); >2254 if (!sd) >2255 return -ENOMEM; >2256 >2257 *per_cpu_ptr(sdd->sd, j) = sd; > > >The address of memory alloced by 'Code B', is stored in memory "Code A', the allocation counter for 'Code A' >is *0*, while 'Code B' is not *0*. Something odd happens here, either it is expected and some ownership changes happened somewhere >, or it is a leak, or it is an accounting problem. > >If a tool can help identify this kind of pattern, that would be great!~ > > >Any suggestions about how to proceed with the memory problem of kernel/sched/topology.c mentioneded > above?, or is it a problem at all? > Update: It seems the memory alloced by 'Code B' could be handovered via claim_allocations: 1530 /* 1531 * NULL the sd_data elements we've used to build the sched_domain and 1532 * sched_group structure so that the subsequent __free_domain_allocs() 1533 * will not free the data we're using. 1534 */ 1535 static void claim_allocations(int cpu, struct sched_domain *sd) So most likely, this is neither a leak nor a accounting issue. False alarm, sorry.... The reason I brought this up is that the profiling data is rich, but a user who is not familiar with code detail could not make much out of it. If a tool can tell whether the system is drifting away somewhere, like a healthcheck based on profiling data, it would be quite helpful. Thanks David ^ permalink raw reply [flat|nested] 14+ messages in thread
* memory alloc profiling seems not work properly during bootup? 2025-01-12 4:41 ` David Wang @ 2025-01-13 8:03 ` David Wang 2025-01-13 21:56 ` Suren Baghdasaryan 0 siblings, 1 reply; 14+ messages in thread From: David Wang @ 2025-01-13 8:03 UTC (permalink / raw) To: Suren Baghdasaryan, kent.overstreet Cc: Hao Ge, akpm, linux-kernel, linux-mm, Hao Ge, Alessio Balsini, Pasha Tatashin, Sourav Panda Hi, More update, When I boot up my system, no alloc_percpu was accounted in kernel/sched/topology.c 996 14 kernel/sched/topology.c:2275 func:__sdt_alloc 80 996 14 kernel/sched/topology.c:2266 func:__sdt_alloc 80 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 80 12388 24 kernel/sched/topology.c:2252 func:__sdt_alloc 80 612 1 kernel/sched/topology.c:1961 func:sched_init_numa 1 And then after suspend/resume, those alloc_percpu shows up. 996 14 kernel/sched/topology.c:2275 func:__sdt_alloc 395 996 14 kernel/sched/topology.c:2266 func:__sdt_alloc 395 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 395 12388 24 kernel/sched/topology.c:2252 func:__sdt_alloc 395 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 70 <--- 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 70 <--- 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 70 <--- 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 70 <--- 612 1 kernel/sched/topology.c:1961 func:sched_init_numa 1 I have my accumulative counter patch and filter out items with 0 accumulative counter, I am almost sure the patch would not cause this accounting issue, but not 100%..... It seems to me, during boot up, some alloc_percpu is not registered. FYI David At 2025-01-12 12:41:10, "David Wang" <00107082@163.com> wrote: > > >At 2025-01-11 22:31:36, "David Wang" <00107082@163.com> wrote: >>Hi, >> >>I have using this feature for a long while, and I believe this memory alloc profiling feature >>is quite powerful. >> >>But, I have been wondering how to use this data, specifically: >>how anomaly could be detected, what pattern should be defined as anomaly? >> >>So far, I have tools collecting those data (via prometheus), make basic analysis, i.e. top-k, group-by or rate. >>Those analysis help me understand my system, but I cannot tell whether it is abnormal or not. >> >>And sometimes I would just read through /proc/allocinfo, trying to pickup something. >>(Sometimes get lucky, actually only once, find the underflow problem weeks ago.) >> >>A tool would be more helpful if it can identify anomalies, and we can add more pattern as develop along. >> >>A pattern may be hard to define, especially when it involves context. For example, >>I happened to notice following strange things recently: >> >> 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc 1025 >> 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc 1025 >> 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 1025 >> 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc 1025 <----- B >> 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 210 >> 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 210 >> 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 210 >> 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 210 <----- A >>Code A >>2230 sdd->sd = alloc_percpu(struct sched_domain *); >>2231 if (!sdd->sd) >>2232 return -ENOMEM; >>2233 >> >>Code B >>2246 for_each_cpu(j, cpu_map) { >> ... >> >>2251 >>2252 sd = kzalloc_node(sizeof(struct sched_domain) + cpumask_size(), >>2253 GFP_KERNEL, cpu_to_node(j)); >>2254 if (!sd) >>2255 return -ENOMEM; >>2256 >>2257 *per_cpu_ptr(sdd->sd, j) = sd; >> >> >>The address of memory alloced by 'Code B', is stored in memory "Code A', the allocation counter for 'Code A' >>is *0*, while 'Code B' is not *0*. Something odd happens here, either it is expected and some ownership changes happened somewhere >>, or it is a leak, or it is an accounting problem. >> >>If a tool can help identify this kind of pattern, that would be great!~ >> >> >>Any suggestions about how to proceed with the memory problem of kernel/sched/topology.c mentioneded >> above?, or is it a problem at all? >> > >Update: > >It seems the memory alloced by 'Code B' could be handovered via claim_allocations: >1530 /* >1531 * NULL the sd_data elements we've used to build the sched_domain and >1532 * sched_group structure so that the subsequent __free_domain_allocs() >1533 * will not free the data we're using. >1534 */ >1535 static void claim_allocations(int cpu, struct sched_domain *sd) > >So most likely, this is neither a leak nor a accounting issue. False alarm, sorry.... > >The reason I brought this up is that the profiling data is rich, but a user who is not familiar >with code detail could not make much out of it. If a tool can tell whether the system is drifting away somewhere, >like a healthcheck based on profiling data, it would be quite helpful. > >Thanks >David > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: memory alloc profiling seems not work properly during bootup? 2025-01-13 8:03 ` memory alloc profiling seems not work properly during bootup? David Wang @ 2025-01-13 21:56 ` Suren Baghdasaryan 2025-01-14 3:35 ` David Wang 0 siblings, 1 reply; 14+ messages in thread From: Suren Baghdasaryan @ 2025-01-13 21:56 UTC (permalink / raw) To: David Wang Cc: kent.overstreet, Hao Ge, akpm, linux-kernel, linux-mm, Hao Ge, Alessio Balsini, Pasha Tatashin, Sourav Panda On Mon, Jan 13, 2025 at 12:04 AM David Wang <00107082@163.com> wrote: > > Hi, > > More update, > > When I boot up my system, no alloc_percpu was accounted in kernel/sched/topology.c > > 996 14 kernel/sched/topology.c:2275 func:__sdt_alloc 80 > 996 14 kernel/sched/topology.c:2266 func:__sdt_alloc 80 > 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 80 > 12388 24 kernel/sched/topology.c:2252 func:__sdt_alloc 80 > 612 1 kernel/sched/topology.c:1961 func:sched_init_numa 1 > > And then after suspend/resume, those alloc_percpu shows up. > > 996 14 kernel/sched/topology.c:2275 func:__sdt_alloc 395 > 996 14 kernel/sched/topology.c:2266 func:__sdt_alloc 395 > 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 395 > 12388 24 kernel/sched/topology.c:2252 func:__sdt_alloc 395 > 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 70 <--- > 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 70 <--- > 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 70 <--- > 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 70 <--- > 612 1 kernel/sched/topology.c:1961 func:sched_init_numa 1 > > I have my accumulative counter patch and filter out items with 0 accumulative counter, > I am almost sure the patch would not cause this accounting issue, but not 100%..... Have you tested this without your accumulative counter patch? IIUC, that patch filters out any allocation which has never been hit. So, if suspend/resume path contains allocations which were never hit before then those allocations would become suddenly visible, like in your case. That's why I'm against filtering allocinfo data in the kernel. Please try this without your patch and see if the data becomes more consistent. Thanks, Suren. > > > It seems to me, during boot up, some alloc_percpu is not registered. > > > FYI > David > > > > At 2025-01-12 12:41:10, "David Wang" <00107082@163.com> wrote: > > > > > >At 2025-01-11 22:31:36, "David Wang" <00107082@163.com> wrote: > >>Hi, > >> > >>I have using this feature for a long while, and I believe this memory alloc profiling feature > >>is quite powerful. > >> > >>But, I have been wondering how to use this data, specifically: > >>how anomaly could be detected, what pattern should be defined as anomaly? > >> > >>So far, I have tools collecting those data (via prometheus), make basic analysis, i.e. top-k, group-by or rate. > >>Those analysis help me understand my system, but I cannot tell whether it is abnormal or not. > >> > >>And sometimes I would just read through /proc/allocinfo, trying to pickup something. > >>(Sometimes get lucky, actually only once, find the underflow problem weeks ago.) > >> > >>A tool would be more helpful if it can identify anomalies, and we can add more pattern as develop along. > >> > >>A pattern may be hard to define, especially when it involves context. For example, > >>I happened to notice following strange things recently: > >> > >> 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc 1025 > >> 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc 1025 > >> 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 1025 > >> 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc 1025 <----- B > >> 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 210 > >> 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 210 > >> 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 210 > >> 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 210 <----- A > >>Code A > >>2230 sdd->sd = alloc_percpu(struct sched_domain *); > >>2231 if (!sdd->sd) > >>2232 return -ENOMEM; > >>2233 > >> > >>Code B > >>2246 for_each_cpu(j, cpu_map) { > >> ... > >> > >>2251 > >>2252 sd = kzalloc_node(sizeof(struct sched_domain) + cpumask_size(), > >>2253 GFP_KERNEL, cpu_to_node(j)); > >>2254 if (!sd) > >>2255 return -ENOMEM; > >>2256 > >>2257 *per_cpu_ptr(sdd->sd, j) = sd; > >> > >> > >>The address of memory alloced by 'Code B', is stored in memory "Code A', the allocation counter for 'Code A' > >>is *0*, while 'Code B' is not *0*. Something odd happens here, either it is expected and some ownership changes happened somewhere > >>, or it is a leak, or it is an accounting problem. > >> > >>If a tool can help identify this kind of pattern, that would be great!~ > >> > >> > >>Any suggestions about how to proceed with the memory problem of kernel/sched/topology.c mentioneded > >> above?, or is it a problem at all? > >> > > > >Update: > > > >It seems the memory alloced by 'Code B' could be handovered via claim_allocations: > >1530 /* > >1531 * NULL the sd_data elements we've used to build the sched_domain and > >1532 * sched_group structure so that the subsequent __free_domain_allocs() > >1533 * will not free the data we're using. > >1534 */ > >1535 static void claim_allocations(int cpu, struct sched_domain *sd) > > > >So most likely, this is neither a leak nor a accounting issue. False alarm, sorry.... > > > >The reason I brought this up is that the profiling data is rich, but a user who is not familiar > >with code detail could not make much out of it. If a tool can tell whether the system is drifting away somewhere, > >like a healthcheck based on profiling data, it would be quite helpful. > > > >Thanks > >David > > > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: memory alloc profiling seems not work properly during bootup? 2025-01-13 21:56 ` Suren Baghdasaryan @ 2025-01-14 3:35 ` David Wang 2025-01-14 18:48 ` Suren Baghdasaryan 0 siblings, 1 reply; 14+ messages in thread From: David Wang @ 2025-01-14 3:35 UTC (permalink / raw) To: Suren Baghdasaryan Cc: kent.overstreet, Hao Ge, akpm, linux-kernel, linux-mm, Hao Ge, Alessio Balsini, Pasha Tatashin, Sourav Panda Hi, At 2025-01-14 05:56:23, "Suren Baghdasaryan" <surenb@google.com> wrote: >On Mon, Jan 13, 2025 at 12:04 AM David Wang <00107082@163.com> wrote: >> >> Hi, >> >> More update, >> >> When I boot up my system, no alloc_percpu was accounted in kernel/sched/topology.c >> >> 996 14 kernel/sched/topology.c:2275 func:__sdt_alloc 80 >> 996 14 kernel/sched/topology.c:2266 func:__sdt_alloc 80 >> 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 80 >> 12388 24 kernel/sched/topology.c:2252 func:__sdt_alloc 80 >> 612 1 kernel/sched/topology.c:1961 func:sched_init_numa 1 >> >> And then after suspend/resume, those alloc_percpu shows up. >> >> 996 14 kernel/sched/topology.c:2275 func:__sdt_alloc 395 >> 996 14 kernel/sched/topology.c:2266 func:__sdt_alloc 395 >> 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 395 >> 12388 24 kernel/sched/topology.c:2252 func:__sdt_alloc 395 >> 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 70 <--- >> 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 70 <--- >> 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 70 <--- >> 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 70 <--- >> 612 1 kernel/sched/topology.c:1961 func:sched_init_numa 1 >> >> I have my accumulative counter patch and filter out items with 0 accumulative counter, >> I am almost sure the patch would not cause this accounting issue, but not 100%..... > >Have you tested this without your accumulative counter patch? >IIUC, that patch filters out any allocation which has never been hit. >So, if suspend/resume path contains allocations which were never hit >before then those allocations would become suddenly visible, like in >your case. That's why I'm against filtering allocinfo data in the >kernel. Please try this without your patch and see if the data becomes >more consistent. I remove all my patch and build a 6.13.0-rc7 kernel, After boot up, 64 1 kernel/sched/topology.c:2579 func:alloc_sched_domains 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 512 1 kernel/sched/topology.c:1961 func:sched_init_numa And after suspend/resume, no change detected: 64 1 kernel/sched/topology.c:2579 func:alloc_sched_domains 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 512 1 kernel/sched/topology.c:1961 func:sched_init_numa I also build a image with accumulative counter, but no filter. After boot up: 64 1 kernel/sched/topology.c:2579 func:alloc_sched_domains 2 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc 80 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc 80 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 80 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc 80 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 0 <---this *0* seems wrong 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 0 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 0 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 0 512 1 kernel/sched/topology.c:1961 func:sched_init_numa 1 And then suspend/resume: 64 1 kernel/sched/topology.c:2579 func:alloc_sched_domains 17 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc 395 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc 395 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 395 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc 395 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 70 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 70 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 70 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 70 512 1 kernel/sched/topology.c:1961 func:sched_init_numa 1 Reading the code, those allocation behaviors should be tied together: if kzalloc_node at line#2252 happened, then alloc_percpu at line#2230 should also happened. kernel/sched/topology.c 2230 sdd->sd = alloc_percpu(struct sched_domain *); 2231 if (!sdd->sd) 2232 return -ENOMEM; ... 2246 for_each_cpu(j, cpu_map) { ... 2252 sd = kzalloc_node(sizeof(struct sched_domain) + cpumask_size(), 2253 GFP_KERNEL, cpu_to_node(j)); ... 2257 *per_cpu_ptr(sdd->sd, j) = sd; But somehow during bootup, those alloc_percpu in kernel/sched/topology.c:__sdt_alloc were missed in profiling. (I am not meant to sell the idea of accumulative counter again here, but it dose help sometimes. :). >Thanks, >Suren. > > >> Thanks David ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: memory alloc profiling seems not work properly during bootup? 2025-01-14 3:35 ` David Wang @ 2025-01-14 18:48 ` Suren Baghdasaryan 2025-01-15 1:27 ` David Wang 0 siblings, 1 reply; 14+ messages in thread From: Suren Baghdasaryan @ 2025-01-14 18:48 UTC (permalink / raw) To: David Wang Cc: kent.overstreet, Hao Ge, akpm, linux-kernel, linux-mm, Hao Ge, Alessio Balsini, Pasha Tatashin, Sourav Panda On Mon, Jan 13, 2025 at 7:36 PM David Wang <00107082@163.com> wrote: > > Hi, > > > At 2025-01-14 05:56:23, "Suren Baghdasaryan" <surenb@google.com> wrote: > >On Mon, Jan 13, 2025 at 12:04 AM David Wang <00107082@163.com> wrote: > >> > >> Hi, > >> > >> More update, > >> > >> When I boot up my system, no alloc_percpu was accounted in kernel/sched/topology.c > >> > >> 996 14 kernel/sched/topology.c:2275 func:__sdt_alloc 80 > >> 996 14 kernel/sched/topology.c:2266 func:__sdt_alloc 80 > >> 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 80 > >> 12388 24 kernel/sched/topology.c:2252 func:__sdt_alloc 80 > >> 612 1 kernel/sched/topology.c:1961 func:sched_init_numa 1 > >> > >> And then after suspend/resume, those alloc_percpu shows up. > >> > >> 996 14 kernel/sched/topology.c:2275 func:__sdt_alloc 395 > >> 996 14 kernel/sched/topology.c:2266 func:__sdt_alloc 395 > >> 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 395 > >> 12388 24 kernel/sched/topology.c:2252 func:__sdt_alloc 395 > >> 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 70 <--- > >> 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 70 <--- > >> 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 70 <--- > >> 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 70 <--- > >> 612 1 kernel/sched/topology.c:1961 func:sched_init_numa 1 > >> > >> I have my accumulative counter patch and filter out items with 0 accumulative counter, > >> I am almost sure the patch would not cause this accounting issue, but not 100%..... > > > >Have you tested this without your accumulative counter patch? > >IIUC, that patch filters out any allocation which has never been hit. > >So, if suspend/resume path contains allocations which were never hit > >before then those allocations would become suddenly visible, like in > >your case. That's why I'm against filtering allocinfo data in the > >kernel. Please try this without your patch and see if the data becomes > >more consistent. > > I remove all my patch and build a 6.13.0-rc7 kernel, > After boot up, > 64 1 kernel/sched/topology.c:2579 func:alloc_sched_domains > 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc > 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc > 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc > 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc > 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc > 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc > 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc > 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc > 512 1 kernel/sched/topology.c:1961 func:sched_init_numa > > And after suspend/resume, no change detected: > 64 1 kernel/sched/topology.c:2579 func:alloc_sched_domains > 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc > 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc > 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc > 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc > 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc > 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc > 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc > 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc > 512 1 kernel/sched/topology.c:1961 func:sched_init_numa > > I also build a image with accumulative counter, but no filter. > > After boot up: > 64 1 kernel/sched/topology.c:2579 func:alloc_sched_domains 2 > 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc 80 > 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc 80 > 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 80 > 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc 80 > 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 0 <---this *0* seems wrong > 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 0 > 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 0 > 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 0 > 512 1 kernel/sched/topology.c:1961 func:sched_init_numa 1 > > And then suspend/resume: > 64 1 kernel/sched/topology.c:2579 func:alloc_sched_domains 17 > 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc 395 > 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc 395 > 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 395 > 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc 395 > 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 70 > 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 70 > 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 70 > 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 70 > 512 1 kernel/sched/topology.c:1961 func:sched_init_numa 1> > Reading the code, those allocation behaviors should be tied together: > if kzalloc_node at line#2252 happened, then alloc_percpu at line#2230 should also happened. Hmm, ok. Looks like early calls to alloc_percpu() are not being registered somehow. Could you please share your cumulative counter patch with me? I'll try to reproduce this locally and see if I can spot the issue. > > kernel/sched/topology.c > 2230 sdd->sd = alloc_percpu(struct sched_domain *); > 2231 if (!sdd->sd) > 2232 return -ENOMEM; > ... > 2246 for_each_cpu(j, cpu_map) { > ... > 2252 sd = kzalloc_node(sizeof(struct sched_domain) + cpumask_size(), > 2253 GFP_KERNEL, cpu_to_node(j)); > ... > 2257 *per_cpu_ptr(sdd->sd, j) = sd; > > > But somehow during bootup, those alloc_percpu in kernel/sched/topology.c:__sdt_alloc were missed in profiling. > (I am not meant to sell the idea of accumulative counter again here, but it dose help sometimes. :). > > >Thanks, > >Suren. > > > > > >> > > Thanks > David ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: memory alloc profiling seems not work properly during bootup? 2025-01-14 18:48 ` Suren Baghdasaryan @ 2025-01-15 1:27 ` David Wang 2025-01-20 21:03 ` Suren Baghdasaryan 0 siblings, 1 reply; 14+ messages in thread From: David Wang @ 2025-01-15 1:27 UTC (permalink / raw) To: Suren Baghdasaryan Cc: kent.overstreet, Hao Ge, akpm, linux-kernel, linux-mm, Hao Ge, Alessio Balsini, Pasha Tatashin, Sourav Panda At 2025-01-15 02:48:13, "Suren Baghdasaryan" <surenb@google.com> wrote: >On Mon, Jan 13, 2025 at 7:36 PM David Wang <00107082@163.com> wrote: >> >> >> I have my accumulative counter patch and filter out items with 0 accumulative counter, >> >> I am almost sure the patch would not cause this accounting issue, but not 100%..... >> > >> >Have you tested this without your accumulative counter patch? >> >IIUC, that patch filters out any allocation which has never been hit. >> >So, if suspend/resume path contains allocations which were never hit >> >before then those allocations would become suddenly visible, like in >> >your case. That's why I'm against filtering allocinfo data in the >> >kernel. Please try this without your patch and see if the data becomes >> >more consistent. >> >> I remove all my patch and build a 6.13.0-rc7 kernel, >> After boot up, >> 64 1 kernel/sched/topology.c:2579 func:alloc_sched_domains >> 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc >> 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc >> 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc >> 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc >> 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc >> 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc >> 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc >> 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc >> 512 1 kernel/sched/topology.c:1961 func:sched_init_numa >> >> And after suspend/resume, no change detected: >> 64 1 kernel/sched/topology.c:2579 func:alloc_sched_domains >> 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc >> 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc >> 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc >> 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc >> 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc >> 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc >> 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc >> 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc >> 512 1 kernel/sched/topology.c:1961 func:sched_init_numa >> >> I also build a image with accumulative counter, but no filter. >> >> After boot up: >> 64 1 kernel/sched/topology.c:2579 func:alloc_sched_domains 2 >> 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc 80 >> 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc 80 >> 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 80 >> 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc 80 >> 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 0 <---this *0* seems wrong >> 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 0 >> 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 0 >> 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 0 >> 512 1 kernel/sched/topology.c:1961 func:sched_init_numa 1 >> >> And then suspend/resume: >> 64 1 kernel/sched/topology.c:2579 func:alloc_sched_domains 17 >> 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc 395 >> 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc 395 >> 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 395 >> 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc 395 >> 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 70 >> 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 70 >> 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 70 >> 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 70 >> 512 1 kernel/sched/topology.c:1961 func:sched_init_numa 1> >> Reading the code, those allocation behaviors should be tied together: >> if kzalloc_node at line#2252 happened, then alloc_percpu at line#2230 should also happened. > >Hmm, ok. Looks like early calls to alloc_percpu() are not being >registered somehow. Could you please share your cumulative counter >patch with me? I'll try to reproduce this locally and see if I can >spot the issue. Sure, here is the patch base on 6.13.0-rc7. diff --git a/include/linux/alloc_tag.h b/include/linux/alloc_tag.h index 0bbbe537c5f9..6ca680604c6d 100644 --- a/include/linux/alloc_tag.h +++ b/include/linux/alloc_tag.h @@ -18,6 +18,7 @@ struct alloc_tag_counters { u64 bytes; u64 calls; + u64 accu_calls; }; /* @@ -124,7 +125,7 @@ static inline bool mem_alloc_profiling_enabled(void) static inline struct alloc_tag_counters alloc_tag_read(struct alloc_tag *tag) { - struct alloc_tag_counters v = { 0, 0 }; + struct alloc_tag_counters v = { 0, 0, 0 }; struct alloc_tag_counters *counter; int cpu; @@ -132,6 +133,7 @@ static inline struct alloc_tag_counters alloc_tag_read(struct alloc_tag *tag) counter = per_cpu_ptr(tag->counters, cpu); v.bytes += counter->bytes; v.calls += counter->calls; + v.accu_calls += counter->accu_calls; } return v; @@ -179,6 +181,7 @@ static inline bool alloc_tag_ref_set(union codetag_ref *ref, struct alloc_tag *t * counter because when we free each part the counter will be decremented. */ this_cpu_inc(tag->counters->calls); + this_cpu_inc(tag->counters->accu_calls); return true; } diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c index 7dcebf118a3e..615833d4fbd7 100644 --- a/lib/alloc_tag.c +++ b/lib/alloc_tag.c @@ -97,6 +97,7 @@ static void alloc_tag_to_text(struct seq_buf *out, struct codetag *ct) seq_buf_printf(out, "%12lli %8llu ", bytes, counter.calls); codetag_to_text(out, ct); + seq_buf_printf(out, " %llu", counter.accu_calls); seq_buf_putc(out, ' '); seq_buf_putc(out, '\n'); } David > >> >> kernel/sched/topology.c >> 2230 sdd->sd = alloc_percpu(struct sched_domain *); >> 2231 if (!sdd->sd) >> 2232 return -ENOMEM; >> ... >> 2246 for_each_cpu(j, cpu_map) { >> ... >> 2252 sd = kzalloc_node(sizeof(struct sched_domain) + cpumask_size(), >> 2253 GFP_KERNEL, cpu_to_node(j)); >> ... >> 2257 *per_cpu_ptr(sdd->sd, j) = sd; >> >> >> But somehow during bootup, those alloc_percpu in kernel/sched/topology.c:__sdt_alloc were missed in profiling. >> (I am not meant to sell the idea of accumulative counter again here, but it dose help sometimes. :). >> >> >Thanks, >> >Suren. >> > >> > >> >> >> >> Thanks >> David ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: memory alloc profiling seems not work properly during bootup? 2025-01-15 1:27 ` David Wang @ 2025-01-20 21:03 ` Suren Baghdasaryan 0 siblings, 0 replies; 14+ messages in thread From: Suren Baghdasaryan @ 2025-01-20 21:03 UTC (permalink / raw) To: David Wang Cc: kent.overstreet, Hao Ge, akpm, linux-kernel, linux-mm, Hao Ge, Alessio Balsini, Pasha Tatashin, Sourav Panda On Tue, Jan 14, 2025 at 5:27 PM David Wang <00107082@163.com> wrote: > > > At 2025-01-15 02:48:13, "Suren Baghdasaryan" <surenb@google.com> wrote: > >On Mon, Jan 13, 2025 at 7:36 PM David Wang <00107082@163.com> wrote: > >> > > >> >> I have my accumulative counter patch and filter out items with 0 accumulative counter, > >> >> I am almost sure the patch would not cause this accounting issue, but not 100%..... > >> > > >> >Have you tested this without your accumulative counter patch? > >> >IIUC, that patch filters out any allocation which has never been hit. > >> >So, if suspend/resume path contains allocations which were never hit > >> >before then those allocations would become suddenly visible, like in > >> >your case. That's why I'm against filtering allocinfo data in the > >> >kernel. Please try this without your patch and see if the data becomes > >> >more consistent. > >> > >> I remove all my patch and build a 6.13.0-rc7 kernel, > >> After boot up, > >> 64 1 kernel/sched/topology.c:2579 func:alloc_sched_domains > >> 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc > >> 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc > >> 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc > >> 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc > >> 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc > >> 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc > >> 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc > >> 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc > >> 512 1 kernel/sched/topology.c:1961 func:sched_init_numa > >> > >> And after suspend/resume, no change detected: > >> 64 1 kernel/sched/topology.c:2579 func:alloc_sched_domains > >> 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc > >> 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc > >> 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc > >> 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc > >> 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc > >> 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc > >> 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc > >> 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc > >> 512 1 kernel/sched/topology.c:1961 func:sched_init_numa > >> > >> I also build a image with accumulative counter, but no filter. > >> > >> After boot up: > >> 64 1 kernel/sched/topology.c:2579 func:alloc_sched_domains 2 > >> 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc 80 > >> 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc 80 > >> 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 80 > >> 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc 80 > >> 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 0 <---this *0* seems wrong > >> 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 0 > >> 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 0 > >> 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 0 > >> 512 1 kernel/sched/topology.c:1961 func:sched_init_numa 1 > >> > >> And then suspend/resume: > >> 64 1 kernel/sched/topology.c:2579 func:alloc_sched_domains 17 > >> 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc 395 > >> 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc 395 > >> 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 395 > >> 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc 395 > >> 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 70 > >> 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 70 > >> 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 70 > >> 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 70 > >> 512 1 kernel/sched/topology.c:1961 func:sched_init_numa 1> > >> Reading the code, those allocation behaviors should be tied together: > >> if kzalloc_node at line#2252 happened, then alloc_percpu at line#2230 should also happened. > > > >Hmm, ok. Looks like early calls to alloc_percpu() are not being > >registered somehow. Could you please share your cumulative counter > >patch with me? I'll try to reproduce this locally and see if I can > > >spot the issue. > > Sure, here is the patch base on 6.13.0-rc7. Thanks and sorry for the delay. It looks like the per-cpu allocations you pointed out happen early enough in the boot process that chunk->obj_exts was not allocated yet. Therefore the check inside pcpu_alloc_tag_alloc_hook() for chunk->obj_exts fails and accounting gets skipped. Allocating obj_exts earlier is not trivial because slab is not available yet. I'll need to look closer into per-cpu code to see how this can be fixed. > > > > > diff --git a/include/linux/alloc_tag.h b/include/linux/alloc_tag.h > index 0bbbe537c5f9..6ca680604c6d 100644 > --- a/include/linux/alloc_tag.h > +++ b/include/linux/alloc_tag.h > @@ -18,6 +18,7 @@ > struct alloc_tag_counters { > u64 bytes; > u64 calls; > + u64 accu_calls; > }; > > /* > @@ -124,7 +125,7 @@ static inline bool mem_alloc_profiling_enabled(void) > > static inline struct alloc_tag_counters alloc_tag_read(struct alloc_tag *tag) > { > - struct alloc_tag_counters v = { 0, 0 }; > + struct alloc_tag_counters v = { 0, 0, 0 }; > struct alloc_tag_counters *counter; > int cpu; > > @@ -132,6 +133,7 @@ static inline struct alloc_tag_counters alloc_tag_read(struct alloc_tag *tag) > counter = per_cpu_ptr(tag->counters, cpu); > v.bytes += counter->bytes; > v.calls += counter->calls; > + v.accu_calls += counter->accu_calls; > } > > return v; > @@ -179,6 +181,7 @@ static inline bool alloc_tag_ref_set(union codetag_ref *ref, struct alloc_tag *t > * counter because when we free each part the counter will be decremented. > */ > this_cpu_inc(tag->counters->calls); > + this_cpu_inc(tag->counters->accu_calls); > return true; > } > > diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c > index 7dcebf118a3e..615833d4fbd7 100644 > --- a/lib/alloc_tag.c > +++ b/lib/alloc_tag.c > @@ -97,6 +97,7 @@ static void alloc_tag_to_text(struct seq_buf *out, struct codetag *ct) > > seq_buf_printf(out, "%12lli %8llu ", bytes, counter.calls); > codetag_to_text(out, ct); > + seq_buf_printf(out, " %llu", counter.accu_calls); > seq_buf_putc(out, ' '); > seq_buf_putc(out, '\n'); > } > > > > David > > > > >> > >> kernel/sched/topology.c > >> 2230 sdd->sd = alloc_percpu(struct sched_domain *); > >> 2231 if (!sdd->sd) > >> 2232 return -ENOMEM; > >> ... > >> 2246 for_each_cpu(j, cpu_map) { > >> ... > >> 2252 sd = kzalloc_node(sizeof(struct sched_domain) + cpumask_size(), > >> 2253 GFP_KERNEL, cpu_to_node(j)); > >> ... > >> 2257 *per_cpu_ptr(sdd->sd, j) = sd; > >> > >> > >> But somehow during bootup, those alloc_percpu in kernel/sched/topology.c:__sdt_alloc were missed in profiling. > >> (I am not meant to sell the idea of accumulative counter again here, but it dose help sometimes. :). > >> > >> >Thanks, > >> >Suren. > >> > > >> > > >> >> > >> > >> Thanks > >> David ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] tools/mm: Introduce a tool to handle entries in allocinfo 2025-01-11 14:31 ` David Wang 2025-01-12 4:41 ` David Wang @ 2025-01-13 21:47 ` Suren Baghdasaryan 1 sibling, 0 replies; 14+ messages in thread From: Suren Baghdasaryan @ 2025-01-13 21:47 UTC (permalink / raw) To: David Wang Cc: kent.overstreet, Hao Ge, akpm, linux-kernel, linux-mm, Hao Ge, Alessio Balsini, Pasha Tatashin, Sourav Panda On Sat, Jan 11, 2025 at 6:32 AM David Wang <00107082@163.com> wrote: > > Hi, Hi David, Sorry for the delay. I'm not ignoring your input, I'm just a bit busy and didn't have time to properly reply to your questions. > > I have using this feature for a long while, and I believe this memory alloc profiling feature > is quite powerful. > > But, I have been wondering how to use this data, specifically: > how anomaly could be detected, what pattern should be defined as anomaly? > > So far, I have tools collecting those data (via prometheus), make basic analysis, i.e. top-k, group-by or rate. > Those analysis help me understand my system, but I cannot tell whether it is abnormal or not. > > And sometimes I would just read through /proc/allocinfo, trying to pickup something. > (Sometimes get lucky, actually only once, find the underflow problem weeks ago.) > > A tool would be more helpful if it can identify anomalies, and we can add more pattern as develop along. You are absolutely correct. An automatic detection of problematic patterns would be the ultimate goal. We are analyzing the data we collect and trying to come up with strategies for identifying such patterns. Simple and obvious pattern for a leak would be constant growth but there might be others like sawtooth pattern or spikes which could point to opportunities to optimize the usage by employing object pools/caches. Categorizing allocations into hierarchical groups and measuring per-group consumption might be another useful technique we are considering. All this is in quite early stages, so ideas and suggestions from people using this API would be very valuable. > > A pattern may be hard to define, especially when it involves context. For example, > I happened to notice following strange things recently: > > 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc 1025 > 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc 1025 > 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 1025 > 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc 1025 <----- B > 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 210 > 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 210 > 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 210 > 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 210 <----- A > Code A > 2230 sdd->sd = alloc_percpu(struct sched_domain *); > 2231 if (!sdd->sd) > 2232 return -ENOMEM; > 2233 > > Code B > 2246 for_each_cpu(j, cpu_map) { > ... > > 2251 > 2252 sd = kzalloc_node(sizeof(struct sched_domain) + cpumask_size(), > 2253 GFP_KERNEL, cpu_to_node(j)); > 2254 if (!sd) > 2255 return -ENOMEM; > 2256 > 2257 *per_cpu_ptr(sdd->sd, j) = sd; > > > The address of memory alloced by 'Code B', is stored in memory "Code A', the allocation counter for 'Code A' > is *0*, while 'Code B' is not *0*. Something odd happens here, either it is expected and some ownership changes happened somewhere > , or it is a leak, or it is an accounting problem. > > If a tool can help identify this kind of pattern, that would be great!~ Hmm. I don't see an easy way to identify such code dependencies from allocinfo data alone. I think that would involve some sophisticated code analysis tooling. > > > Any suggestions about how to proceed with the memory problem of kernel/sched/topology.c mentioneded > above?, or is it a problem at all? From your follow-up email, it looks like you already found the answer :) Thanks, Suren. > > > Thanks > David > > > > > At 2025-01-07 05:11:47, "Suren Baghdasaryan" <surenb@google.com> wrote: > >On Mon, Jan 6, 2025 at 3:22 AM Hao Ge <hao.ge@linux.dev> wrote: > >> > >> From: Hao Ge <gehao@kylinos.cn> > >> > >> Some users always say that the information provided by /proc/allocinfo > >> is too extensive or bulky. > >> > > > >CC'ing Alessio along with Pasha and Sourav who were interested in such a tool. > > > >Hi Hao, > >Thanks for the tool! Actually Alessio just developed a tool called > >alloctop (similar to slabtop) which I think will do what you want and > >more. It supports sorting, filtering, continuous update, etc. It's > >written in Rust and we are planning to upstream it once we finish > >testing and evaluating it on Android. Please take a look and see if it > >fits your usecase. Please also note that this tool has been > >implemented just last week, so hot off the press and might have some > >early bugs. > >Thanks, > >Suren. > > > >[1] https://cs.android.com/android/platform/superproject/main/+/main:system/memory/libmeminfo/tools/alloctop/src/ > > > >> > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] tools/mm: Introduce a tool to handle entries in allocinfo 2025-01-06 11:21 [PATCH] tools/mm: Introduce a tool to handle entries in allocinfo Hao Ge 2025-01-06 21:11 ` Suren Baghdasaryan @ 2025-01-09 0:19 ` kernel test robot 1 sibling, 0 replies; 14+ messages in thread From: kernel test robot @ 2025-01-09 0:19 UTC (permalink / raw) To: Hao Ge, akpm, surenb, kent.overstreet Cc: oe-kbuild-all, linux-kernel, linux-mm, hao.ge, Hao Ge Hi Hao, kernel test robot noticed the following build warnings: [auto build test WARNING on akpm-mm/mm-everything] [also build test WARNING on linus/master v6.13-rc6 next-20250108] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Hao-Ge/tools-mm-Introduce-a-tool-to-handle-entries-in-allocinfo/20250106-192419 base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything patch link: https://lore.kernel.org/r/20250106112103.25401-1-hao.ge%40linux.dev patch subject: [PATCH] tools/mm: Introduce a tool to handle entries in allocinfo compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250109/202501090823.W7WjUFM1-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202501090823.W7WjUFM1-lkp@intel.com/ All warnings (new ones prefixed by >>): >> allocinfo_tool.c:126:1: warning: non-void function does not return a value in all control paths [-Wreturn-type] 126 | } | ^ 1 warning generated. page-types.c:1003:28: warning: operator '?:' has lower precedence than '+'; '+' will be evaluated first [-Wparentheses] 1003 | end = off + sigbus_addr ? sigbus_addr - ptr : 0; | ~~~~~~~~~~~~~~~~~ ^ page-types.c:1003:28: note: place parentheses around the '+' expression to silence this warning 1003 | end = off + sigbus_addr ? sigbus_addr - ptr : 0; | ^ | ( ) page-types.c:1003:28: note: place parentheses around the '?:' expression to evaluate it first 1003 | end = off + sigbus_addr ? sigbus_addr - ptr : 0; | ^ | ( ) 1 warning generated. -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2025-01-20 21:04 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2025-01-06 11:21 [PATCH] tools/mm: Introduce a tool to handle entries in allocinfo Hao Ge 2025-01-06 21:11 ` Suren Baghdasaryan 2025-01-07 15:11 ` Alessio Balsini 2025-01-08 1:16 ` Hao Ge 2025-01-11 14:31 ` David Wang 2025-01-12 4:41 ` David Wang 2025-01-13 8:03 ` memory alloc profiling seems not work properly during bootup? David Wang 2025-01-13 21:56 ` Suren Baghdasaryan 2025-01-14 3:35 ` David Wang 2025-01-14 18:48 ` Suren Baghdasaryan 2025-01-15 1:27 ` David Wang 2025-01-20 21:03 ` Suren Baghdasaryan 2025-01-13 21:47 ` [PATCH] tools/mm: Introduce a tool to handle entries in allocinfo Suren Baghdasaryan 2025-01-09 0:19 ` kernel test robot
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox