Messages in this thread | | | Date | Wed, 01 Jul 2015 15:21:37 -0400 | From | Sasha Levin <> | Subject | Re: [PATCH 05/11] mm: debug: dump page into a string rather than directly on screen |
| |
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.
Or for VMAs, from include/linux/rmap.h:
VM_BUG_ON_VMA(vma->anon_vma != next->anon_vma, vma);
Would it be interesting to see both vma, and next? Probably.
Or opportunities to add information from other variables, such as in:
VM_BUG_ON_PAGE(stable_node->kpfn != page_to_pfn(oldpage), oldpage);
Is stable_node->kpfn interesting? Might be.
We *could* go ahead and open code all of that, but that's not happening, It's not intuitive and people just slap VM_BUG_ON()s and hope they can figure it out when those VM_BUG_ON()s happen.
Are there any pieces of code that open code what you suggested?
Thanks, Sasha
| |