On 13 Jan 2020, at 20:01, Matthew Wilcox wrote: > On Mon, Jan 13, 2020 at 10:34:16PM +0000, Chris Mason wrote: >>> I think what I want is a bio I can reach from current, somehow. And >>> the >>> plug feels like a natural place to keep it because it's basically >>> saying >>> "I want to do lots of little IOs and have them combined". The fact >>> that >>> the iomap code has a bio that it precombines fragments into suggests >>> to >>> me that the existing antifragmentation code in the plugging >>> mechanism >>> isn't good enough. So let's make it better by storing a bio in the >>> plug >>> and then we can get rid of the bio in the iomap code. >> >> Both btrfs and xfs do this, we have a bio that we pass around and >> build >> and submit. We both also do some gymnastics in writepages to avoid >> waiting for the bios we've been building to finish while we're >> building >> them. >> >> I love the idea of the plug api having a way to hold that for us, but >> sometimes we really are building the bios, and we don't want the plug >> to >> let it go if we happen to schedule. > > The plug wouldn't have to let the bio go. I appreciate the plug does > let > requests go on context switch, but it wouldn't have to let the bio go. > This bio is being stored on the stack, just as now, so it's still > there. Plugging is great because it's building up state for the block layer across a wide variety of MM and FS code. btrfs and xfs are building state for themselves across a tiny cross section of their own code. I'd rather not complicate magic state in current in places we can easily pass the bio down. -chris
