On 8/8/23 3:33?AM, Hao Xu wrote: > On 8/1/23 08:28, Jens Axboe wrote: >> On 7/31/23 9:26?AM, Darrick J. Wong wrote: >>> I've watched quite a bit of NOWAIT whackamole going on over the past few >>> years (i_rwsem, the ILOCK, the IO layer, memory allocations...). IIRC >>> these filesystem ios all have to run in process context, right? If so, >>> why don't we capture the NOWAIT state in a PF flag? We already do that >>> for NOFS/NOIO memory allocations to make sure that /all/ reclaim >>> attempts cannot recurse into the fs/io stacks. >> >> I would greatly prefer passing down the context rather than capitulating >> and adding a task_struct flag for this. I think it _kind of_ makes sense >> for things like allocations, as you cannot easily track that all the way >> down, but it's a really ugly solution. It certainly creates more churn >> passing it down, but it also reveals the parts that need to check it. >> WHen new code is added, it's much more likely you'll spot the fact that >> there's passed in context. For allocation, you end up in the allocator >> anyway, which can augment the gfp mask with whatever is set in the task. >> The same is not true for locking and other bits, as they don't return a >> value to begin with. When we know they are sane, we can flag the fs as >> supporting it (like we've done for async buffered reads, for example). >> >> It's also not an absolute thing, like memory allocations are. It's >> perfectly fine to grab a mutex under NOWAIT issue. What you should not > > Hi Jens, > To make sure, I'd like to ask, for memory allocation, GFP_NOIO semantics > is all we need in NOWAIT issue, GFP_NOWAIT is not necessary, do I > understand it right? Yep, GFP_NOIO should be just fine. -- Jens Axboe
