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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox