On Fri, Feb 05, 2021 at 01:58:06PM -0800, John Hubbard wrote: > On 2/5/21 1:52 PM, Suren Baghdasaryan wrote: > > > > > I takes your suggestion something like this. > > > > > > > > > > [alloc_range] could be order or range by interval > > > > > > > > > > /sys/kernel/mm/cma/cma-A/[alloc_range]/success > > > > > /sys/kernel/mm/cma/cma-A/[alloc_range]/fail > > > > > .. > > > > > .. > > > > > /sys/kernel/mm/cma/cma-Z/[alloc_range]/success > > > > > /sys/kernel/mm/cma/cma-Z/[alloc_range]/fail > > > > The interface above seems to me the most useful actually, if by > > [alloc_range] you mean the different allocation orders. This would > > cover Minchan's per-CMA failure tracking and would also allow us to > > understand what kind of allocations are failing and therefore if the > > problem is caused by pinning/fragmentation or by over-utilization. > > > > I agree. That seems about right, now that we've established that > cma areas are a must-have. Okay, now we agreed the dirction right now so let me do that in next version. If you don't see it's reasonable, let me know. * I will drop the number of CMA *page* allocation attemtps/failures to make simple start * I will keep CMA allocation attemtps/failures * They will be under /sys/kernel/mm/cma/cma-XX/success,fail * It will turn on CONFIG_CMA && CONFIG_SYSFS Orthognal work(diffrent patchset) * adding global CMA alloc/fail into vmstat * adding alloc_range success/failure under CONFIG_CMA_ALLOC_TRACKING whatever configuration or just by default if everyone agree Thanks.
