On Mon 13-05-19 04:21:07, Matthew Wilcox wrote: > On Mon, May 13, 2019 at 12:51:38PM +0200, Michal Hocko wrote: > > On Fri 10-05-19 06:50:23, Matthew Wilcox wrote: > > > This is a little more serious attempt than v1, since nobody seems opposed > > > to the concept of using GFP flags to pass the order around. I've split > > > it up a bit better, and I've reversed the arguments of __alloc_pages_node > > > to match the order of the arguments to other functions in the same family. > > > alloc_pages_node() needs the same treatment, but there's about 70 callers, > > > so I'm going to skip it for now. > > > > > > This is against current -mm. I'm seeing a text saving of 482 bytes from > > > a tinyconfig vmlinux (1003785 reduced to 1003303). There are more > > > savings to be had by combining together order and the gfp flags, for > > > example in the scan_control data structure. > > > > So what is the primary objective here? Reduce the code size? Reduce the > > registers pressure? Please tell us more why changing the core allocator > > API and make it more subtle is worth it. > > The primary objective here is to avoid adding an 'order' parameter to > pagecache_get_page(). It would be great to state that explicitly in the changelog. Because that has some clear goal to achieve and that we can weigh. > I don't think it makes the API more subtle; I see > it as fundamental to the allocation API as any of the other GFP flags. Well, that really depends on how you look at it. Size, allocation restrictions and numa placing can be viewed as orthogonal attributes of the allocation. On the other hand the vast majority of callers do care about order-0 requests and that's where you get most out of the change so it makes some sense to me as well. I can imagine that this can optimize some code paths nicely. That being said, I am not really opposing this change, I would just appreciate to give us full picture of where the motivation comes from. -- Michal Hocko SUSE Labs
