On 07/05/20 4:37 pm, Vlastimil Babka wrote: > 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. > I think that would be in setup_per_cpu_pageset(). After the pagesets for the populated zone have been allocated. - Sandipan
