From: David Rientjes <rientjes@google.com>
To: Sasha Levin <sasha.levin@oracle.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, kirill@shutemov.name
Subject: Re: [PATCH 05/11] mm: debug: dump page into a string rather than directly on screen
Date: Wed, 8 Jul 2015 16:58:26 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.10.1507081653220.16585@chino.kir.corp.google.com> (raw)
In-Reply-To: <55946EA9.2080805@oracle.com>
On Wed, 1 Jul 2015, Sasha Levin wrote:
> Since we'd BUG at VM_BUG_ON(), this would be something closer to:
>
> if (unlikely(compound_head(page) != head)) {
> dump_page(page);
> dump_page(head);
> VM_BUG_ON(1);
> }
>
I was thinking closer to
if (VM_WARN_ON(compound_head(page) != head)) {
...
BUG();
}
so we prefix all output with the typical warning diagnostics, emit
whatever page, vma, etc output we want, and then finally die. The final
BUG() here would have to be replaced by something that suppresses the
repeated output.
If it's really just a warning, then no BUG() needed.
> But my point here was that while one *could* do it that way, no one does because
> it's not intuitive. We both agree that in the example above it would be useful to
> see both 'page' and 'head', and yet the code that was written didn't dump any of
> them. Why? No one wants to write debug code unless it's easy and short.
>
pr_alert("%pZp %pZv", page, vma) isn't shorter than dump_page(page);
dump_vma(vma), but it would be a line shorter. I'm not sure that the
former is easier, though, and it prevents us from ever expanding dump_*()
functions for conditional output.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-07-08 23:58 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-14 17:10 [PATCH 00/11] mm: debug: formatting memory management structs Sasha Levin
2015-05-14 17:10 ` [PATCH 01/11] mm: debug: format flags in a buffer Sasha Levin
2015-05-14 17:10 ` [PATCH 02/11] mm: debug: deal with a new family of MM pointers Sasha Levin
2015-05-14 17:10 ` [PATCH 03/11] mm: debug: dump VMA into a string rather than directly on screen Sasha Levin
2015-05-14 17:10 ` [PATCH 04/11] mm: debug: dump struct MM " Sasha Levin
2015-05-14 17:10 ` [PATCH 05/11] mm: debug: dump page " Sasha Levin
2015-06-30 23:35 ` David Rientjes
2015-07-01 8:53 ` Kirill A. Shutemov
2015-07-01 19:21 ` Sasha Levin
2015-07-01 21:25 ` David Rientjes
2015-07-01 21:34 ` Kirill A. Shutemov
2015-07-01 22:33 ` Vlastimil Babka
2015-07-01 22:50 ` Sasha Levin
2015-07-08 23:58 ` David Rientjes [this message]
2015-08-06 15:08 ` Sasha Levin
2015-05-14 17:10 ` [PATCH 06/11] mm: debug: clean unused code Sasha Levin
2015-05-14 17:10 ` [PATCH 07/11] mm: debug: VM_BUG() Sasha Levin
2015-05-14 17:10 ` [PATCH 08/11] mm: debug: kill VM_BUG_ON_PAGE Sasha Levin
2015-05-14 17:10 ` [PATCH 09/11] mm: debug: kill VM_BUG_ON_VMA Sasha Levin
2015-05-14 17:10 ` [PATCH 10/11] mm: debug: kill VM_BUG_ON_MM Sasha Levin
2015-05-14 17:10 ` [PATCH 11/11] mm: debug: use VM_BUG() to help with debug output Sasha Levin
2015-05-14 20:24 ` [PATCH 00/11] mm: debug: formatting memory management structs Andrew Morton
2015-05-14 20:26 ` Sasha Levin
2015-06-26 21:34 ` Sasha Levin
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=alpine.DEB.2.10.1507081653220.16585@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sasha.levin@oracle.com \
/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