Hi, Michal, Michal Hocko <mhocko@xxxxxxxxxx> writes: > On Fri 24-03-17 06:56:10, Dave Hansen wrote: >> On 03/24/2017 12:33 AM, John Hubbard wrote: >> > There might be some additional information you are using to come up with >> > that conclusion, that is not obvious to me. Any thoughts there? These >> > calls use the same underlying page allocator (and I thought that both >> > were subject to the same constraints on defragmentation, as a result of >> > that). So I am not seeing any way that kmalloc could possibly be a >> > less-fragmenting call than vmalloc. >> >> You guys are having quite a discussion over a very small point. >> >> But, Ying is right. >> >> Let's say we have a two-page data structure. vmalloc() takes two >> effectively random order-0 pages, probably from two different 2M pages >> and pins them. That "kills" two 2M pages. >> >> kmalloc(), allocating two *contiguous* pages, is very unlikely to cross >> a 2M boundary (it theoretically could). That means it will only "kill" >> the possibility of a single 2M page. More 2M pages == less fragmentation. > > Yes I agree with this. And the patch is no brainer. kvmalloc makes sure > to not try too hard on the kmalloc side so I really didn't get the > objection about direct compaction and reclaim which initially started > this discussion. Besides that the swapon path usually happens early > during the boot where we should have those larger blocks available. Could I add your Acked-by for this patch? Best Regards, Huang, Ying -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
