On 5/7/20 11:08 AM, Sandipan Das wrote: >>> >>> This is certainly an improvement. Thanks! The question whether we can >>> identify where bogus numbers came from would be interesting as well. >>> Maybe those are not worth fixing but it would be great to understand >>> them at least. I have to say that the explanation via boot_pageset is >>> not really clear to me. >>> >> >> The documentation update will definitely help. Thanks for that. Thanks both, will send a proper patch. >> I did collect some stack traces on a ppc64 guest for calls to zone_statistics() >> in case of zones that are using the boot_pageset and most of them originate >> from kmem_cache_init() with eventual calls to allocate_slab(). >> >> [ 0.000000] [c00000000282b690] [c000000000402d98] zone_statistics+0x138/0x1d0 >> [ 0.000000] [c00000000282b740] [c000000000401190] rmqueue_pcplist+0xf0/0x120 >> [ 0.000000] [c00000000282b7d0] [c00000000040b178] get_page_from_freelist+0x2f8/0x2100 >> [ 0.000000] [c00000000282bb30] [c000000000401ae0] __alloc_pages_nodemask+0x1a0/0x2d0 >> [ 0.000000] [c00000000282bbc0] [c00000000044b040] alloc_slab_page+0x70/0x580 >> [ 0.000000] [c00000000282bc20] [c00000000044b5f8] allocate_slab+0xa8/0x610 >> ... >> >> In the remaining cases, the sources are ftrace_init() and early_trace_init(). >> > > Forgot to add that this happens during the period between zone_pcp_init() and setup_zone_pageset(). If you can identify a good moment during the boot when the boot_pageset stops being used, maybe we could just reset its stats to zero once at that point and be done with it. > - Sandipan >
