From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 In-Reply-To: <20160120214546.GX6033@dastard> References: <20160112022548.GD6033@dastard> <20160112033708.GE6033@dastard>

<20160115202131.GH6330@kvack.org> <20160120195957.GV6033@dastard> <20160120204449.GC12249@kvack.org> <20160120214546.GX6033@dastard> Date: Wed, 20 Jan 2016 15:07:26 -0800 Message-ID: Subject: Re: [PATCH 07/13] aio: enabled thread based async fsync From: Linus Torvalds To: Dave Chinner Cc: Al Viro , Andrew Morton , linux-fsdevel , Linux API , Benjamin LaHaise , Linux Kernel Mailing List , linux-aio@kvack.org, linux-mm Content-Type: multipart/alternative; boundary=089e0112d074afd1c50529cc0c44 Sender: owner-linux-mm@kvack.org List-ID: --089e0112d074afd1c50529cc0c44 Content-Type: text/plain; charset=UTF-8 On Jan 20, 2016 1:46 PM, "Dave Chinner" wrote: > > > > > That said, I also agree that it would be interesting to hear what the > > > performance impact is for existing performance-sensitive users. Could > > > we make that "aio_may_use_threads()" case be unconditional, making > > > things simpler? > > > > Making it unconditional is a goal, but some work is required before that > > can be the case. The O_DIRECT issue is one such matter -- it requires some > > changes to the filesystems to ensure that they adhere to the non-blocking > > nature of the new interface (ie taking i_mutex is a Bad Thing that users > > really do not want to be exposed to; if taking it blocks, the code should > > punt to a helper thread). > > Filesystems *must take locks* in the IO path. I agree. I also would prefer to make the aio code have as little interaction and magic flags with the filesystem code as humanly possible. I wonder if we could make the rough rule be that the only synchronous case the aio code ever has is more or less entirely in the generic vfs caches? IOW, could we possibly aim to make the rule be that if we call down to the filesystem layer, we do that within a thread? We could do things like that for the name loopkup for openat() too, where we could handle the successful RCU loopkup synchronously, but then if we fall out of RCU mode we'd do the thread. Linus --089e0112d074afd1c50529cc0c44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Jan 20, 2016 1:46 PM, "Dave Chinner" <david@fromorbit.com> wrote:
> >
> > > That said, I also agree that it would be interesting to hear= what the
> > > performance impact is for existing performance-sensitive use= rs. Could
> > > we make that "aio_may_use_threads()" case be uncon= ditional, making
> > > things simpler?
> >
> > Making it unconditional is a goal, but some work is required befo= re that
> > can be the case.=C2=A0 The O_DIRECT issue is one such matter -- i= t requires some
> > changes to the filesystems to ensure that they adhere to the non-= blocking
> > nature of the new interface (ie taking i_mutex is a Bad Thing tha= t users
> > really do not want to be exposed to; if taking it blocks, the cod= e should
> > punt to a helper thread).
>
> Filesystems *must take locks* in the IO path.

I agree.

I also would prefer to make the aio code have as little inte= raction and magic flags with the filesystem code as humanly possible.

I wonder if we could make the rough rule be that the only sy= nchronous case the aio code ever has is more or less entirely in the generi= c vfs caches? IOW, could we possibly aim to make the rule be that if we cal= l down to the filesystem layer, we do that within a thread?

We could do things like that for the name loopkup for openat= () too, where we could handle the successful RCU loopkup synchronously, but= then if we fall out of RCU mode we'd do the thread.

=C2=A0=C2=A0=C2=A0 Linus

--089e0112d074afd1c50529cc0c44-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org