Re: [PATCH v2 00/15] Remove 'order' argument from many mm functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux