On Mon, May 06, 2019 at 09:05:58PM -0700, Matthew Wilcox wrote: > From: "Matthew Wilcox (Oracle)" <willy@xxxxxxxxxxxxx> > > 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?
