Thread (8 messages) 8 messages, 5 authors, 2021-05-31

Re: [RFC PATCH] mm: dump_page: print total mapcount for compound page

From: Matthew Wilcox <willy@infradead.org>
Date: 2021-05-28 18:22:32
Also in: lkml

On Fri, May 28, 2021 at 10:54:03AM -0700, Yang Shi wrote:
So I prepared this patch to show a possible approach to get some
feedback.  The same thing could be decoded by the reader of page dump
as well by using the same formula used by this patch.  However it sounds
more convenient to have kernel do the math.
You haven't taken enough things into consideration ...
+	bool is_slab = PageSlab(head);
We should probably have a separate dump_slab_page().  Almost nothing
in __dump_page() is really useful for slab pages (eg, mapping, index,
mapcount, compound_mapcount, compound_pincount, aops), and the flags
(such as are used) have different meanings.
+		nr = compound_nr(head);
+		if (is_slab)
+			total_mapcount = 0;
+		else if (PageHuge(head))
+			total_mapcount = comp_mapcnt;
+		else {
+			if (mapping) {
+				if (!PageAnon(head))
+					nr = nr * (comp_mapcnt + 1) - comp_mapcnt;
+			} else
+				nr = 0;
+			total_mapcount = refcount - pincount - nr;
I see what you're trying to do here, but there are so many other things
which take a refcount on a page.  The LRU, the page cache, private fs
data, random temporary "gets" (eg, buffered reads, buffered writes,
get_user_pages(), readahead, truncate, migration).  I think this is
likely to be so inaccurate as to be confusing.

I had to think hard about it though.  I like what you're trying to do,
I just don't think it works ;-(
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help