On Thu, May 09, 2019 at 02:07:55PM +0300, Kirill A. Shutemov wrote: > On Mon, May 06, 2019 at 09:05:58PM -0700, Matthew Wilcox wrote: > > 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? It's stored in a few structs that might not appreciate it growing, like struct address_space. I've been vaguely wondering about how to combine order, gfp_t and nodeid into one parameter in a way that doesn't grow those structs, but I don't have a solid idea yet.
