From: Matthew Wilcox <willy@infradead.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jens Axboe <axboe@kernel.dk>, Miklos Szeredi <miklos@szeredi.hu>,
Christian Brauner <brauner@kernel.org>,
linux-fsdevel@vger.kernel.org, linux-unionfs@vger.kernel.org,
Jiufei Xue <jiufei.xue@linux.alibaba.com>
Subject: Re: [PATCH] ovl: punt write aio completion to workqueue
Date: Thu, 28 Sep 2023 10:22:01 +0100 [thread overview]
Message-ID: <ZRVFuReyZGbIXOBM@casper.infradead.org> (raw)
In-Reply-To: <CAOQ4uxjC6qif-MZqkLUsd0RixD0xVHVuGDT=7HCX0kcY1okv2A@mail.gmail.com>
On Thu, Sep 28, 2023 at 12:15:00PM +0300, Amir Goldstein wrote:
> On Thu, Sep 28, 2023 at 10:08 AM Jens Axboe <axboe@kernel.dk> wrote:
> > On 9/28/23 12:46 AM, Amir Goldstein wrote:
> > > ret = -ENOMEM;
> > > aio_req = kmem_cache_zalloc(ovl_aio_request_cachep, GFP_KERNEL);
> > > if (!aio_req)
> >
> > Unrelated to this patch, but is this safe? You're allocating an aio_req
> > from within the ->write_iter() handler, yet it's GFP_KERNEL? Seems like
> > that should at least be GFP_NOFS, no?
>
> I could be wrong, but since overlayfs does not have any page cache
> of its own, I don't think memory reclaim poses a risk.
Use the scoped APIs, people! GFP_NOFS needs to die. If your filesystem
cannot tolerate being reentered, call memalloc_nofs_save() / restore()
when it can tolerate being reentered.
> > That aside, punting to a workqueue is a very heavy handed solution to
> > the problem. Maybe it's the only one you have, didn't look too closely
> > at it, but it's definitely not going to increase your performance...
>
> I bet it won't... but I need to worry about correctness.
>
> What I would like to know, and that is something that I tried
> to ask you in the Link: discussion, but perhaps I wasn't clear -
> Are there any IOCB flags that the completion caller may set,
> that will hint the submitter that completion is not from interrupt
> context and that punting to workqueue is not needed?
I'd really like page cache write completions to not be handled in
the interrupt handler. Then we could make the i_pages lock not an
interrupt-disabling lock any more. I think that'd best be handled in a
workqueue too, but maybe there's a better solution nowadays.
prev parent reply other threads:[~2023-09-28 9:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-28 6:46 [PATCH] ovl: punt write aio completion to workqueue Amir Goldstein
2023-09-28 7:08 ` Jens Axboe
2023-09-28 9:15 ` Amir Goldstein
2023-09-28 9:22 ` Matthew Wilcox [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZRVFuReyZGbIXOBM@casper.infradead.org \
--to=willy@infradead.org \
--cc=amir73il@gmail.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=jiufei.xue@linux.alibaba.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).