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(). 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. It's a change, to be sure, but I think it's a worthwhile one.
