On Thu, Mar 11, 2021 at 08:48:27AM +0000, Mel Gorman wrote: > I don't have that information unfortunately. It's a chicken and egg > problem because without the API, there is no point creating new users. > For example, fault around or readahead could potentially batch pages > but whether it is actually noticable when page zeroing has to happen > is a completely different story. It's a similar story for SLUB, we know > lower order allocations hurt some microbenchmarks like hackbench-sockets > but have not quantified what happens if SLUB batch allocates pages when > high-order allocations fail. I'm planning on reducing overhead in the readahead path by allocating higher-order pages rather than by allocating a batch of order-0 pages. With the old ->readpages interface, it would have made sense to allocate a batch of pages, but with the new ->readahead interface, we put the pages into the page cache for the filesystem, so it doesn't make as much sense any more. Right now, measuring performance in the readahead path is hard because we end up contending against kswapd that's trying to evict all the clean pages that we earlier readahead into this same file. Could avoid that by having N files, each about half the size of memory, but then we restart the readahead algorithm for each file ... I feel like the real solution for that is to do a GFP_NOWAIT allocation, then try to evict earlier pages for the same file we're working on so that kswapd doesn't get woken up if we're just streaming a read through a gargantuan file. But I should probably talk to Johannes first.
