On Sat, 2018-04-07 at 23:54 -0700, Matthew Wilcox wrote: > Please explain: > > commit 6a15674d1e90917f1723a814e2e8c949000440f7 > Author: Bart Van Assche <bart.vanassche@xxxxxxx> > Date: Thu Nov 9 10:49:54 2017 -0800 > > block: Introduce blk_get_request_flags() > > A side effect of this patch is that the GFP mask that is passed to > several allocation functions in the legacy block layer is changed > from GFP_KERNEL into __GFP_DIRECT_RECLAIM. > > Why was this thought to be a good idea? I think gfp.h is pretty clear: > > * Useful GFP flag combinations that are commonly used. It is recommended > * that subsystems start with one of these combinations and then set/clear > * __GFP_FOO flags as necessary. > > Instead, the block layer now throws away all but one bit of the > information being passed in by the callers, and all it tells the allocator > is whether or not it can start doing direct reclaim. I can see that > you may well be in a situation where you don't want to start more I/O, > but your caller knows that! Why make the allocator work harder than > it has to? In particular, why isn't the page allocator allowed to wake > up kswapd to do reclaim in non-atomic context, but is when the caller > is in atomic context? __GFP_KSWAPD_RECLAIM wasn't stripped off on purpose for non-atomic allocations. That was an oversight. Do you perhaps want me to prepare a patch that makes blk_get_request() again respect the full gfp mask passed as third argument to blk_get_request()? Bart.
