On 8/8/23 12:34, 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?
Thanks,
Hao
Trying to find a lock in mem allocation process that GFP_NOIO holds it while
other normal GFP_* like GFP_KERNEL also holds it and does IO.
Failed to find one such lock. So I guess though GFP_NOIO may cause sleep
but won't wait on IO.
