Re: [RFC 00/11] Remove 'order' argument from many mm functions

Kirill A. Shutemov
2019-05-14T13:16:57Z

On Mon, May 06, 2019 at 09:05:58PM -0700, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> It's possible to save a few hundred bytes from the kernel text by moving
> the 'order' argument into the GFP flags. I had the idea while I was
> playing with THP pagecache (notably, I didn't want to add an 'order'
> parameter to pagecache_get_page())
>
> What I got for a -tiny config for page_alloc.o (with a tinyconfig,
> x86-32) after each step:
>
> text data bss dec hex filename
> 21462 349 44 21855 555f 1.o
> 21447 349 44 21840 5550 2.o
> 21415 349 44 21808 5530 3.o
> 21399 349 44 21792 5520 4.o
> 21399 349 44 21792 5520 5.o
> 21367 349 44 21760 5500 6.o
> 21303 349 44 21696 54c0 7.o
> 21303 349 44 21696 54c0 8.o
> 21303 349 44 21696 54c0 9.o
> 21303 349 44 21696 54c0 A.o
> 21303 349 44 21696 54c0 B.o
>
> I assure you that the callers all shrink as well. vmscan.o also
> shrinks, but I didn't keep detailed records.
>
> Anyway, this is just a quick POC due to me being on an aeroplane for
> most of today. Maybe we don't want to spend five GFP bits on this.
> Some bits of this could be pulled out and applied even if we don't want
> to go for the main objective. eg rmqueue_pcplist() doesn't use its
> gfp_flags argument.

I like the idea. But I'm somewhat worried about running out of bits in
gfp_t. Is there anything preventing us to bump gfp_t to u64 in the future?