On 1/3/19 3:22 PM, Michal Hocko wrote: > On Thu 03-01-19 14:53:47, Qian Cai wrote: >> On 1/3/19 2:07 PM, Michal Hocko wrote> So can we make the revert with an >> explanation that the patch was wrong? >>> If we want to make hacks to catch more objects to be tracked then it >>> would be great to have some numbers in hands. >> >> Well, those numbers are subject to change depends on future start_kernel() >> order. Right now, there are many functions could be caught earlier by page owner. >> >> kmemleak_init(); > [...] >> sched_init_smp(); > > The kernel source dump will not tell us much of course. A ball park > number whether we are talking about dozen, hundreds or thousands of > allocations would tell us something at least, doesn't it. > > Handwaving that it might help us some is not particurarly useful. We are > already losing some allocations already. Does it matter? Well, that > depends, sometimes we do want to catch an owner of particular page and > it is sad to find nothing. But how many times have you or somebody else > encountered that in practice. That is exactly a useful information to > judge an ugly ifdefery in the code. See my point? Here is the number without DEFERRED_STRUCT_PAGE_INIT. == page_ext_init() after page_alloc_init_late() == Node 0, zone DMA: page owner found early allocated 0 pages Node 0, zone DMA32: page owner found early allocated 7009 pages Node 0, zone Normal: page owner found early allocated 85827 pages Node 4, zone Normal: page owner found early allocated 75063 pages == page_ext_init() before kmemleak_init() == Node 0, zone DMA: page owner found early allocated 0 pages Node 0, zone DMA32: page owner found early allocated 6654 pages Node 0, zone Normal: page owner found early allocated 41907 pages Node 4, zone Normal: page owner found early allocated 41356 pages So, it told us that it will miss tens of thousands of early page allocation call sites.
