On Mon, Nov 15, 2021 at 02:50:26PM -0800, Mina Almasry wrote: > PM_THP_MAPPED sounds good to me. > > TBH I think I still prefer this approach because it's a very simple 2 > line patch which addresses the concrete use case I have well. I'm not > too familiar with the smaps code to be honest but I think adding a > range-based smaps API will be a sizeable patch to add a syscall, > handle a stable interface, and handle cases where the memory range > doesn't match a VMA boundary. I'm not sure the performance benefit > would justify this patch and I'm not sure the extra info from smaps > would be widely useful. However if you insist and folks believe this > is the better approach I can prototype a range-based smaps and test > its performance to see if it works for us as well, just let me know > what kind of API you're envisioning. Yeah indeed I haven't yet thought enough on such a new interface, it's just that I think it'll be something that solves a broader range of requests including the thp-aware issue, so I raised it up. That shouldn't require a lot code change either afaiu, as smap_gather_stats() already takes a "start" and I think what's missing is another end where we just pass in 0 when we want the default vma->vm_end as the end of range. I don't have a solid clue on other use case to ask for that more generic interface, so please feel free to move on with it. If you'll need a repost to address the comment from Andrew on removing the debugging lines, please also consider using the shorter PM_THP_MAPPED then it looks good to me too. Thanks! -- Peter Xu
