* [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 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
* 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: [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: 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
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