From: John Hubbard <jhubbard@nvidia.com>
To: Matthew Wilcox <willy@infradead.org>, <linux-mm@kvack.org>
Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH] mm: Improve dump_page() for compound pages
Date: Sat, 8 Feb 2020 17:18:01 -0800 [thread overview]
Message-ID: <96e1f693-0e7b-2817-f13d-1946ff7654a1@nvidia.com> (raw)
In-Reply-To: <20200208044415.30012-1-willy@infradead.org>
On 2/7/20 8:44 PM, Matthew Wilcox wrote:
...
> - if (PageCompound(page))
> - pr_warn("page:%px refcount:%d mapcount:%d mapping:%px "
> - "index:%#lx compound_mapcount: %d\n",
> - page, page_ref_count(page), mapcount,
> - page->mapping, page_to_pgoff(page),
> - compound_mapcount(page));
> + if (compound)
> + pr_warn("page:%px refcount:%d mapcount:%d mapping:%p "
> + "index:%#lx head:%px order:%u compound_mapcount:%d\n",
> + page, page_ref_count(head), mapcount,
> + mapping, page_to_pgoff(page), head,
> + compound_order(head), compound_mapcount(page));
OK, so the patch now produces the following output for a normal page and a huge page:
page:ffffea0011f68540 refcount:1025 mapcount:1 mapping:00000000b9ef1410 index:0x0
anon flags: 0x17ffe0000080036(referenced|uptodate|lru|active|swapbacked)
raw: 017ffe0000080036 ffffea0011f684c8 ffffea0010eeab88 ffff888495396581
raw: 0000000000000000 0000000000000000 0000040100000000 0000000000000000
page dumped because: test: dump_page()
page:ffffea0010ed2740 refcount:513 mapcount:1 mapping:00000000b9ef1410 index:0xb2 head:ffffea0010ed0000 order:9 compound_mapcount:1
anon flags: 0x17ffe0000000000()
raw: 017ffe0000000000 ffffea0010ed0001 ffffea0010ed2748 dead000000000400
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
head: 017ffe0000090036 ffffea0011ff8ec8 ffffea0010ed8008 ffff888495396581
head: 0000000000000015 0000000000000000 00000201ffffffff 0000000000000000
page dumped because: test: dump_page()
...which is looking very good!
Minor point: How do you and everyone feel about the line length? I do see it getting
pretty long, and I'm about to add the following to it, as a separate patch on top of this:
"compound_pincount:N"
...which just makes it even worse. And on some serial terminals this can get cut
off, so I'm wondering if maybe doing another pr_warn(), and a duplicated page pointer
output, to break up the line would help, like this output:
page:ffffea0010ed2740 refcount:513 mapcount:1 mapping:00000000b9ef1410 index:0xb2 head:ffffea0010ed0000
page:ffffea0010ed2740 order:9 compound_mapcount:1
anon flags: 0x17ffe0000000000()
raw: 017ffe0000000000 ffffea0010ed0001 ffffea0010ed2748 dead000000000400
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
head: 017ffe0000090036 ffffea0011ff8ec8 ffffea0010ed8008 ffff888495396581
head: 0000000000000015 0000000000000000 00000201ffffffff 0000000000000000
page dumped because: test: dump_page()
...which then becomes this, in a future patch:
page:ffffea0010ed2740 refcount:513 mapcount:1 mapping:00000000b9ef1410 index:0xb2 head:ffffea0010ed0000
page:ffffea0010ed2740 order:9 compound_mapcount:1 compound_pincount:1
anon flags: 0x17ffe0000000000()
raw: 017ffe0000000000 ffffea0010ed0001 ffffea0010ed2748 dead000000000400
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
head: 017ffe0000090036 ffffea0011ff8ec8 ffffea0010ed8008 ffff888495396581
head: 0000000000000015 0000000000000000 00000201ffffffff 0000000000000000
page dumped because: test: dump_page()
...or is it best in your experience to leave that line as an "atomic" print statement?
thanks,
--
John Hubbard
NVIDIA
> else
> - pr_warn("page:%px refcount:%d mapcount:%d mapping:%px index:%#lx\n",
> + pr_warn("page:%px refcount:%d mapcount:%d mapping:%p index:%#lx\n",
> page, page_ref_count(page), mapcount,
> - page->mapping, page_to_pgoff(page));
> + mapping, page_to_pgoff(page));
> if (PageKsm(page))
> type = "ksm ";
> else if (PageAnon(page))
> @@ -106,6 +115,10 @@ void __dump_page(struct page *page, const char *reason)
> print_hex_dump(KERN_WARNING, "raw: ", DUMP_PREFIX_NONE, 32,
> sizeof(unsigned long), page,
> sizeof(struct page), false);
> + if (head != page)
> + print_hex_dump(KERN_WARNING, "head: ", DUMP_PREFIX_NONE, 32,
> + sizeof(unsigned long), head,
> + sizeof(struct page), false);
>
> if (reason)
> pr_warn("page dumped because: %s\n", reason);
>
next prev parent reply other threads:[~2020-02-09 1:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-08 4:44 [PATCH] mm: Improve dump_page() for compound pages Matthew Wilcox
2020-02-08 4:48 ` Matthew Wilcox
2020-02-09 1:09 ` John Hubbard
2020-02-09 1:12 ` Matthew Wilcox
2020-02-09 1:18 ` John Hubbard [this message]
2020-02-10 12:42 ` Kirill A. Shutemov
2020-02-10 19:50 ` John Hubbard
2020-02-10 21:21 ` Kirill A. Shutemov
2020-02-10 21:33 ` John Hubbard
2020-02-10 21:54 ` Kirill A. Shutemov
2020-02-10 22:00 ` John Hubbard
2020-02-10 22:02 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=96e1f693-0e7b-2817-f13d-1946ff7654a1@nvidia.com \
--to=jhubbard@nvidia.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-mm@kvack.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.