linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Sasha Levin <sasha.levin@oracle.com>
To: David Rientjes <rientjes@google.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, 01 Jul 2015 18:50:17 -0400	[thread overview]
Message-ID: <55946EA9.2080805@oracle.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1507011422070.14014@chino.kir.corp.google.com>

On 07/01/2015 05:25 PM, David Rientjes wrote:
> On Wed, 1 Jul 2015, Sasha Levin wrote:
> 
>> On 06/30/2015 07:35 PM, David Rientjes wrote:
>>> I don't know how others feel, but this looks strange to me and seems like 
>>> it's only a result of how we must now dump page information 
>>> (dump_page(page) is no longer available, we must do pr_alert("%pZp", 
>>> page)).
>>>
>>> Since we're relying on print formats, this would arguably be better as
>>>
>>> 	pr_alert("Not movable balloon page:\n");
>>> 	pr_alert("%pZp", page);
>>>
>>> to avoid introducing newlines into potentially lengthy messages that need 
>>> a specified loglevel like you've done above.
>>>
>>> But that's not much different than the existing dump_page() 
>>> implementation.
>>>
>>> So for this to be worth it, it seems like we'd need a compelling usecase 
>>> for something like pr_alert("%pZp %pZv", page, vma) and I'm not sure we're 
>>> ever actually going to see that.  I would argue that
>>>
>>> 	dump_page(page);
>>> 	dump_vma(vma);
>>>
>>> would be simpler in such circumstances.
>>
>> I think we can find usecases where we want to dump more information than what's
>> contained in just one page/vma/mm struct. Things like the following from mm/gup.c:
>>
>> 	VM_BUG_ON_PAGE(compound_head(page) != head, page);
>>
>> Where seeing 'head' would be interesting as well.
>>
> 
> I think it's a debate about whether this would be better off handled as
> 
> 	if (VM_BUG_ON(compound_head(page) != head)) {
> 		dump_page(page);
> 		dump_page(head);
> 	}

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);
	}

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.

> and avoid VM_BUG_ON_PAGE() and the new print formats entirely.  We can 
> improve upon existing VM_BUG_ON(), and BUG_ON() itself since the VM isn't 
> anything special in this regard, to print diagnostic information that may 
> be helpful, but I don't feel like adding special VM_BUG_ON_*() macros or 
> printing formats makes any of this simpler.

This patchset actually kills the VM_BUG_ON_*() macros for exactly that reason:
VM isn't special at all and doesn't need it's own magic code in the form of
VM_BUG_ON_*() macros and dump_*() functions.


Thanks,
Sasha

--
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>

  parent reply	other threads:[~2015-07-01 23:00 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 [this message]
2015-07-08 23:58           ` David Rientjes
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=55946EA9.2080805@oracle.com \
    --to=sasha.levin@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.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