Re: [PATCH v9 00/14] io-uring/xfs: support async buffered writes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 22, 2022 at 06:50:29PM -0600, Jens Axboe wrote:
> On 6/22/22 6:29 PM, Darrick J. Wong wrote:
> > On Wed, Jun 22, 2022 at 04:27:07PM -0600, Jens Axboe wrote:
> >> On Thu, 16 Jun 2022 14:22:07 -0700, Stefan Roesch wrote:
> >>> This patch series adds support for async buffered writes when using both
> >>> xfs and io-uring. Currently io-uring only supports buffered writes in the
> >>> slow path, by processing them in the io workers. With this patch series it is
> >>> now possible to support buffered writes in the fast path. To be able to use
> >>> the fast path the required pages must be in the page cache, the required locks
> >>> in xfs can be granted immediately and no additional blocks need to be read
> >>> form disk.
> >>>
> >>> [...]
> >>
> >> Applied, thanks!
> >>
> >> [01/14] mm: Move starting of background writeback into the main balancing loop
> >>         commit: 29c36351d61fd08a2ed50a8028a7f752401dc88a
> >> [02/14] mm: Move updates of dirty_exceeded into one place
> >>         commit: a3fa4409eec3c094ad632ac1029094e061daf152
> >> [03/14] mm: Add balance_dirty_pages_ratelimited_flags() function
> >>         commit: 407619d2cef3b4d74565999a255a17cf5d559fa4
> >> [04/14] iomap: Add flags parameter to iomap_page_create()
> >>         commit: 49b5cd0830c1e9aa0f9a3717ac11a74ef23b9d4e
> >> [05/14] iomap: Add async buffered write support
> >>         commit: ccb885b4392143cea1bdbd8a0f35f0e6d909b114
> >> [06/14] iomap: Return -EAGAIN from iomap_write_iter()
> >>         commit: f0f9828d64393ea2ce87bd97f033051c8d7a337f
> > 
> > I'm not sure /what/ happened here, but I never received the full V9
> > series, and neither did lore:
> > 
> > https://lore.kernel.org/linux-fsdevel/165593682792.161026.12974983413174964699.b4-ty@xxxxxxxxx/T/#t
> 
> Huh yes, didn't even notice that it's missing a few.
> 
> > As it is, I already have my hands full trying to figure out why
> > generic/522 reports file corruption after 20 minutes of running on
> > vanilla 5.19-rc3, so I don't think I'm going to get to this for a while
> > either.
> > 
> > The v8 series looked all right to me, but ********* I hate how our
> > development process relies on such unreliable **** tooling.  I don't
> 
> Me too, and the fact that email is getting worse and worse is not making
> things any better...
> 
> > think it's a /great/ idea to be pushing new code into -next when both
> > the xfs and pagecache maintainers are too busy to read the whole thing
> > through... but did hch actually RVB the whole thing prior to v9?
> 
> Yes, hch did review the whole thing prior to v9. v9 has been pretty
> quiet, but even v8 didn't have a whole lot. Which is to be expected for
> a v9, this thing has been going for months.

<nod>

> We're only at -rc3 right now, so I think it's fine getting it some -next
> exposure. It's not like it's getting pushed tomorrow, and if actual
> concerns arise, let's just deal with them if that's the case. I'll check
> in with folks before anything gets pushed certainly, I just don't think
> it's fair to keep stalling when there are no real objections. Nothing
> gets pushed unless the vested parties agree, obviously.

Ok.  Would you or Stefan mind sending the whole v9 series again, so I
can have one more look?  Hopefully vger won't just eat the series a
third time... :(

Huh.  Ok.  LWN seems to have gotten the whole thing:
https://lwn.net/ml/linux-mm/20220616212221.2024518-1-shr@xxxxxx/

I'll go read that in the meantime.  $DEITY I hate email.

--D

> -- 
> Jens Axboe
> 




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux