On 1/13/20 3:27 PM, Matthew Wilcox wrote:

On Mon, Jan 13, 2020 at 03:14:26PM -0700, Jens Axboe wrote:

quoted

On 1/13/20 3:10 PM, Matthew Wilcox wrote:

quoted

On Mon, Jan 13, 2020 at 03:00:40PM -0700, Jens Axboe wrote:

quoted

On 1/13/20 2:58 PM, Matthew Wilcox wrote:

quoted

On Mon, Jan 13, 2020 at 06:00:52PM +0000, Chris Mason wrote:

quoted

This is true, I didn't explain that part well ;)  Depending on 
compression etc we might end up poking the xarray inside the actual IO 
functions, but the main difference is that btrfs is building a single 
bio.  You're moving the plug so you'll merge into single bio, but I'd 
rather build 2MB bios than merge them.

Why don't we store a bio pointer inside the plug?  You're opencoding that,
iomap is opencoding that, and I bet there's a dozen other places where
we pass a bio around.  Then blk_finish_plug can submit the bio.

Plugs aren't necessarily a bio, they can be callbacks too.

I'm thinking something as simple as this:

It's a little odd imho, the plugging generally collect requests. Sounds
what you're looking for is some plug owner private data, which just
happens to be a bio in this case?

Is this over repeated calls to some IO generating helper? Would it be
more efficient if that helper could generate the full bio in one go,
instead of piecemeal?

The issue is around ->readpages.  Take a look at how iomap_readpages
works, for example.  We're under a plug (taken in mm/readahead.c),
but we still go through the rigamarole of keeping a pointer to the bio
in ctx.bio and passing ctx around so that we don't end up with many
fragments which have to be recombined into a single bio at the end.

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.

But it doesn't fit the plug model very well. If you get preempted, it
could go away. Or if you have nested plugs, it also won't work at all. I
think it's much saner to keep the "current" bio _outside_ of the plug,
and work on it in peace until you want to submit it.

-- 
Jens Axboe