On 11/24/2020 1:11 PM, Michal Hocko wrote: > On Mon 23-11-20 20:40:40, Charan Teja Kalla wrote: >> >> Thanks Michal! >> On 11/23/2020 7:43 PM, Michal Hocko wrote: >>> On Mon 23-11-20 19:33:16, Charan Teja Reddy wrote: >>>> When the pages are failed to get isolate or migrate, the page owner >>>> information along with page info is dumped. If there are continuous >>>> failures in migration(say page is pinned) or isolation, the log buffer >>>> is simply getting flooded with the page owner information. As most of >>>> the times page info is sufficient to know the causes for failures of >>>> migration or isolation, place the page owner information under DEBUG_VM. >>> >>> I do not see why this path is any different from others that call >>> dump_page. Page owner can add a very valuable information to debug >>> the underlying reasons for failures here. It is an opt-in debugging >>> feature which needs to be enabled explicitly. So I would argue users >>> are ready to accept a lot of data in the kernel log. >> >> Just thinking how frequently failures can happen in those paths. In the >> memory hotplug path, we can flood the page owner logs just by making one >> page pinned. > > If you are operating on a movable zone then pages shouldn't be pinned > for unbound amount of time. Yeah there are some ways to break this > fundamental assumption but this is a bigger problem that needs a > solution. > >> Say If it is anonymous page, the page owner information >> shows is something like below, which is not really telling anything >> other than how the pinned page is allocated. > > Well you can tell an anonymous page from __dump_page, all right, but > this is not true universally. > >> page last allocated via order 0, migratetype Movable, gfp_mask >> 0x100dca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO) >> prep_new_page+0x7c/0x1a4 >> get_page_from_freelist+0x1ac/0x1c4 >> __alloc_pages_nodemask+0x12c/0x378 >> do_anonymous_page+0xac/0x3b4 >> handle_pte_fault+0x2a4/0x3bc >> __handle_speculative_fault+0x208/0x3c0 >> do_page_fault+0x280/0x508 >> do_translation_fault+0x3c/0x54 >> do_mem_abort+0x64/0xf4 >> el0_da+0x1c/0x20 >> page last free stack trace: >> free_pcp_prepare+0x320/0x454 >> free_unref_page_list+0x9c/0x2a4 >> release_pages+0x370/0x3c8 >> free_pages_and_swap_cache+0xdc/0x10c >> tlb_flush_mmu+0x110/0x134 >> tlb_finish_mmu+0x48/0xc0 >> unmap_region+0x104/0x138 >> __do_munmap+0x2ec/0x3b4 >> __arm64_sys_munmap+0x80/0xd8 >> >> I see at some places in the kernel where they put the dump_page under >> DEBUG_VM, but in the end I agree that it is up to the users need. Then >> there are some users who don't care for these page owner logs. > > Well, as I've said page_owner requires an explicit enabling and I would > expect that if somebody enables this tracking then it is expected to see > the information when we dump a page state. > >> And an issue on Embedded systems with these continuous logs being >> printed to the console is the watchdog timeouts, because console logging >> happens by disabling the interrupts. > > Are you enabling page_owner on those systems unconditionally? > Yes, We do always enable the page owner on just the internal debug builds for memory analysis, But never on the production kernels. And on these builds excessive logging, at times because of a pinned page, causing the watchdog timeouts, is the problem. -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
