On Tue 21-01-20 11:38:29, Anshuman Khandual wrote: > > > On 01/20/2020 03:52 PM, Michal Hocko wrote: > > On Mon 20-01-20 11:04:14, Wei Yang wrote: > >> Now we can pass all bad reasons to __dump_page(). > > And we do we want to do that? The dump of the page will tell us the > > whole story so a single and the most important reason sounds like a > > better implementation. The code is also more subtle because each caller > > of the function has to be aware of how many reasons there might be. > > Not to mention that you need a room for 5 pointers on the stack and this > > and page allocator might be called from deeper call chains. > > > > Two paths which lead to __dump_page(), dump_page() and bad_page(). > Callers of dump_page() can give a single reason what they consider the > most important which leads to page dumping. This makes sense but gets > trickier in bad_page() path. At present, free_pages_check_bad() and > check_new_page_bad() has a sequence of 'if' statements which decides > "most important" reason for __dump_page() without much rationale and > similar in case of free_tail_pages_check() as well. As all information > about the page for corresponding reasons are printed with __dump_page() > anyways, do free_pages_check_bad() or check_new_page_bad() really need > to provide any particular single reason ? Do you see any particular problem with the existing logic? I find a single reason sufficient and a good lead for what to check most of the time. -- Michal Hocko SUSE Labs
