Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1344923 > unrolled thread
| Started by | Sergey Senozhatsky <sergey.senozhatsky@gmail.com> |
|---|---|
| First post | 2016-02-27 07:30 +0100 |
| Last post | 2016-02-29 07:30 +0100 |
| Articles | 3 — 3 participants |
Back to article view | Back to linux.kernel
[PATCH] mm/zsmalloc: add compact column to pool stat Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-02-27 07:30 +0100
Re: [PATCH] mm/zsmalloc: add compact column to pool stat Minchan Kim <minchan@kernel.org> - 2016-02-29 07:10 +0100
Re: [PATCH] mm/zsmalloc: add compact column to pool stat Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-02-29 07:30 +0100
| From | Sergey Senozhatsky <sergey.senozhatsky@gmail.com> |
|---|---|
| Date | 2016-02-27 07:30 +0100 |
| Subject | [PATCH] mm/zsmalloc: add compact column to pool stat |
| Message-ID | <r6Gy5-7hl-1@gated-at.bofh.it> |
Add a new column to pool stats, which will tell us class' zs_can_compact()
number, so it will be easier to analyze zsmalloc fragmentation.
At the moment, we have only numbers of FULL and ALMOST_EMPTY classes, but
they don't tell us how badly the class is fragmented internally.
The new /sys/kernel/debug/zsmalloc/zramX/classes output look as follows:
class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage compact
[..]
12 224 0 2 146 5 8 4 4
13 240 0 0 0 0 0 1 0
14 256 1 13 1840 1672 115 1 10
15 272 0 0 0 0 0 1 0
[..]
49 816 0 3 745 735 149 1 2
51 848 3 4 361 306 76 4 8
52 864 12 14 378 268 81 3 21
54 896 1 12 117 57 26 2 12
57 944 0 0 0 0 0 3 0
[..]
Total 26 131 12709 10994 1071 134
For example, from this particular output we can easily conclude that class-896
is heavily fragmented -- it occupies 26 pages, 12 can be freed by compaction.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
---
mm/zsmalloc.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 43e4cbc..046d364 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -494,6 +494,8 @@ static void __exit zs_stat_exit(void)
debugfs_remove_recursive(zs_stat_root);
}
+static unsigned long zs_can_compact(struct size_class *class);
+
static int zs_stats_size_show(struct seq_file *s, void *v)
{
int i;
@@ -501,14 +503,15 @@ static int zs_stats_size_show(struct seq_file *s, void *v)
struct size_class *class;
int objs_per_zspage;
unsigned long class_almost_full, class_almost_empty;
- unsigned long obj_allocated, obj_used, pages_used;
+ unsigned long obj_allocated, obj_used, pages_used, compact;
unsigned long total_class_almost_full = 0, total_class_almost_empty = 0;
unsigned long total_objs = 0, total_used_objs = 0, total_pages = 0;
+ unsigned long total_compact = 0;
- seq_printf(s, " %5s %5s %11s %12s %13s %10s %10s %16s\n",
+ seq_printf(s, " %5s %5s %11s %12s %13s %10s %10s %16s %7s\n",
"class", "size", "almost_full", "almost_empty",
"obj_allocated", "obj_used", "pages_used",
- "pages_per_zspage");
+ "pages_per_zspage", "compact");
for (i = 0; i < zs_size_classes; i++) {
class = pool->size_class[i];
@@ -521,6 +524,7 @@ static int zs_stats_size_show(struct seq_file *s, void *v)
class_almost_empty = zs_stat_get(class, CLASS_ALMOST_EMPTY);
obj_allocated = zs_stat_get(class, OBJ_ALLOCATED);
obj_used = zs_stat_get(class, OBJ_USED);
+ compact = zs_can_compact(class);
spin_unlock(&class->lock);
objs_per_zspage = get_maxobj_per_zspage(class->size,
@@ -528,23 +532,25 @@ static int zs_stats_size_show(struct seq_file *s, void *v)
pages_used = obj_allocated / objs_per_zspage *
class->pages_per_zspage;
- seq_printf(s, " %5u %5u %11lu %12lu %13lu %10lu %10lu %16d\n",
+ seq_printf(s, " %5u %5u %11lu %12lu %13lu"
+ " %10lu %10lu %16d %7lu\n",
i, class->size, class_almost_full, class_almost_empty,
obj_allocated, obj_used, pages_used,
- class->pages_per_zspage);
+ class->pages_per_zspage, compact);
total_class_almost_full += class_almost_full;
total_class_almost_empty += class_almost_empty;
total_objs += obj_allocated;
total_used_objs += obj_used;
total_pages += pages_used;
+ total_compact += compact;
}
seq_puts(s, "\n");
- seq_printf(s, " %5s %5s %11lu %12lu %13lu %10lu %10lu\n",
+ seq_printf(s, " %5s %5s %11lu %12lu %13lu %10lu %10lu %16s %7lu\n",
"Total", "", total_class_almost_full,
total_class_almost_empty, total_objs,
- total_used_objs, total_pages);
+ total_used_objs, total_pages, "", total_compact);
return 0;
}
--
2.7.1
[toc] | [next] | [standalone]
| From | Minchan Kim <minchan@kernel.org> |
|---|---|
| Date | 2016-02-29 07:10 +0100 |
| Message-ID | <r7pbQ-6Z8-5@gated-at.bofh.it> |
| In reply to | #1344923 |
On Sat, Feb 27, 2016 at 03:23:53PM +0900, Sergey Senozhatsky wrote: > Add a new column to pool stats, which will tell us class' zs_can_compact() > number, so it will be easier to analyze zsmalloc fragmentation. Just nitpick: Strictly speaking, zs_can_compact number is number of "ideal freeable page by compaction". How about using high level term in description rather than function name? > > At the moment, we have only numbers of FULL and ALMOST_EMPTY classes, but > they don't tell us how badly the class is fragmented internally. > > The new /sys/kernel/debug/zsmalloc/zramX/classes output look as follows: > > class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage compact > [..] > 12 224 0 2 146 5 8 4 4 > 13 240 0 0 0 0 0 1 0 > 14 256 1 13 1840 1672 115 1 10 > 15 272 0 0 0 0 0 1 0 > [..] > 49 816 0 3 745 735 149 1 2 > 51 848 3 4 361 306 76 4 8 > 52 864 12 14 378 268 81 3 21 > 54 896 1 12 117 57 26 2 12 > 57 944 0 0 0 0 0 3 0 > [..] > Total 26 131 12709 10994 1071 134 > > For example, from this particular output we can easily conclude that class-896 > is heavily fragmented -- it occupies 26 pages, 12 can be freed by compaction. How about using "freeable" or something which could represent "freeable"? IMO, it's more strightforward for user. Other than that, Acked-by: Minchan Kim <minchan@kernel.org> Thanks for the nice job!
[toc] | [prev] | [next] | [standalone]
| From | Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> |
|---|---|
| Date | 2016-02-29 07:30 +0100 |
| Message-ID | <r7pvb-7gU-5@gated-at.bofh.it> |
| In reply to | #1345514 |
Hello, On (02/29/16 15:02), Minchan Kim wrote: > On Sat, Feb 27, 2016 at 03:23:53PM +0900, Sergey Senozhatsky wrote: > > Add a new column to pool stats, which will tell us class' zs_can_compact() > > number, so it will be easier to analyze zsmalloc fragmentation. > > Just nitpick: > > Strictly speaking, zs_can_compact number is number of "ideal freeable page > by compaction". How about using high level term in description rather than > function name? OK, makes sense. > > At the moment, we have only numbers of FULL and ALMOST_EMPTY classes, but > > they don't tell us how badly the class is fragmented internally. > > > > The new /sys/kernel/debug/zsmalloc/zramX/classes output look as follows: > > > > class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage compact > > [..] > > 12 224 0 2 146 5 8 4 4 > > 13 240 0 0 0 0 0 1 0 > > 14 256 1 13 1840 1672 115 1 10 > > 15 272 0 0 0 0 0 1 0 > > [..] > > 49 816 0 3 745 735 149 1 2 > > 51 848 3 4 361 306 76 4 8 > > 52 864 12 14 378 268 81 3 21 > > 54 896 1 12 117 57 26 2 12 > > 57 944 0 0 0 0 0 3 0 > > [..] > > Total 26 131 12709 10994 1071 134 > > > > For example, from this particular output we can easily conclude that class-896 > > is heavily fragmented -- it occupies 26 pages, 12 can be freed by compaction. > > How about using "freeable" or something which could represent "freeable"? > IMO, it's more strightforward for user. OK. didn't want to put any long column name there, which would bloat the output. will take a look. > Other than that, > > Acked-by: Minchan Kim <minchan@kernel.org> > > > Thanks for the nice job! thanks. -ss
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web