On Mon, Jul 31, 2023 at 08:26:23AM -0700, Darrick J. Wong wrote: > On Mon, Jul 31, 2023 at 10:13:21AM +0200, Christian Brauner wrote: > > On Mon, Jul 31, 2023 at 11:33:05AM +1000, Dave Chinner wrote: > > > On Thu, Jul 27, 2023 at 04:27:30PM +0200, Christian Brauner wrote: > > > But as I said in the "llseek for io-uring" thread, we need to stop > > > the game of whack-a-mole passing random nowait boolean flags to VFS > > > operations before it starts in earnest. We really need a common > > > context structure (like we have a kiocb for IO operations) that > > > holds per operation control state so we have consistency across all > > > the operations that we need different behaviours for. > > > > Yes, I tend to agree and thought about the same. But right now we don't > > have a lot of context. So I would lean towards a flag argument at most. > > > > But I also wouldn't consider it necessarily wrong to start with booleans > > or a flag first and in a couple of months if the need for more context > > arises we know what kind of struct we want or need. > > I'm probably missing a ton of context (because at the end of the day I > don't care all that much about NOWAIT and still have never installed > liburing) but AFAICT the goal seems to be that for a given io request, > uring tries to execute it with trylocks in the originating process > context. If that attempt fails, it'll punt the io to a workqueue and > rerun the request with blocking locks. Right? Yes, that might be the case for the VFS level code we are talking about right now.... ... but, for example, I have no clue what task context nvmet_file_execute_rw() runs in but it definitely issues file IO with IOCB_NOWAIT... > 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. Interesting idea. That would mean the high level code would have to toggle the task flags before calling into the VFS, which means we'd have to capture RWF_NOWAIT flags at the syscall level rather than propagating them into the iocb. That may impact speed racers, because the RWF flag propagation has been a target of significant micro-optimisation since io_uring came along.... > "I prefer EAGAIN errors to this process blocking" doesn't seem all that > much different. But, what do I know... Yeah, I can see how that might be advantageous from an API persepective, though my gut says "that's a can of worms" but I haven't spent enough time thinking about it to work out why I feel that way. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
