From: Linus Torvalds <torvalds@linux-foundation.org> To: Dave Chinner <david@fromorbit.com> Cc: Benjamin LaHaise <bcrl@kvack.org>, linux-aio@kvack.org, linux-fsdevel <linux-fsdevel@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux API <linux-api@vger.kernel.org>, linux-mm <linux-mm@kvack.org>, Alexander Viro <viro@zeniv.linux.org.uk>, Andrew Morton <akpm@linux-foundation.org> Subject: Re: [PATCH 07/13] aio: enabled thread based async fsync Date: Mon, 11 Jan 2016 20:03:41 -0800 [thread overview] Message-ID: <CA+55aFyLb8scNSYb19rK4iT_Vx5=hKxqPwRHVnETzAhEev0aHw@mail.gmail.com> (raw) In-Reply-To: <20160112033708.GE6033@dastard> On Mon, Jan 11, 2016 at 7:37 PM, Dave Chinner <david@fromorbit.com> wrote: > > Yes, I heard you the first time, but you haven't acknowledged that > the aio fsync interface is indeed different because it already > exists. What's the problem with implementing an AIO call that we've > advertised as supported for many years now that people are asking us > to implement it? Oh, I don't disagree with that. I think it should be exposed, my point was that that too was not enough. I don't see why you argue. You said "that's not enough". And I jjust said that your expansion wasn't sufficient either, and that I think we should strive to expand things even more. And preferably not in some ad-hoc manner. Expand it to *everything* we can do. > As for a generic async syscall interface, why not just add > IOCB_CMD_SYSCALL that encodes the syscall number and parameters > into the iovec structure and let the existing aio subsystem handle > demultiplexing it and handing them off to threads/workqueues/etc? That would likely be the simplest approach, yes. There's a few arguments against it, though: - doing the indirect system call thing does end up being architecture-specific, so now you do need the AIO code to call into some arch wrapper. Not a huge deal, since the arch wrapper will be pretty simple (and we can have a default one that just returns ENOSYS, so that we don't have to synchronize all architectures) - the aio interface really is horrible crap. Really really. For example, the whole "send signal as a completion model" is so f*cking broken that I really don't want to extend the aio interface too much. I think it's unfixable. So I really think we'd be *much* better off with a new interface entirely - preferably one that allows the old aio interfaces to fall out fairly naturally. Ben mentioned lio_listio() as a reason for why he wanted to extend the AIO interface, but I think it works the other way around: yes, we should look at lio_listio(), but we should look at it mainly as a way to ask ourselves: "can we implement a new aynchronous system call submission model that would also make it possible to implement lio_listio() as a user space wrapper around it". For example, if we had an actual _good_ way to queue up things, you could probably make that "struct sigevent" completion for lio_listio() just be another asynchronous system call at the end of the list - a system call that sends the completion signal. And the aiocb_list[] itself? Maybe those could just be done as normal (individual) aio calls (so that you end up having the aiocb that you can wait on with aio_suspend() etc). But then people who do *not* want the crazy aiocb, and do *not* want some SIGIO or whatever, could just fire off asynchronous system calls without that cruddy interface. So my argument is really that I think it would be better to at least look into maybe creating something less crapulent, and striving to make it easy to make the old legacy interfaces be just wrappers around a more capable model. And hey, it may be that in the end nobody cares enough, and the right thing (or at least the prudent thing) to do is to just pile the crap on deeper and higher, and just add a single IOCB_CMD_SYSCALL indirection entry. So I'm not dismissing that as a solution - I just don't think it's a particularly clean one. It does have the advantage of likely being a fairly simple hack. But it smells like a hack. Linus
WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds@linux-foundation.org> To: Dave Chinner <david@fromorbit.com> Cc: Benjamin LaHaise <bcrl@kvack.org>, linux-aio@kvack.org, linux-fsdevel <linux-fsdevel@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux API <linux-api@vger.kernel.org>, linux-mm <linux-mm@kvack.org>, Alexander Viro <viro@zeniv.linux.org.uk>, Andrew Morton <akpm@linux-foundation.org> Subject: Re: [PATCH 07/13] aio: enabled thread based async fsync Date: Mon, 11 Jan 2016 20:03:41 -0800 [thread overview] Message-ID: <CA+55aFyLb8scNSYb19rK4iT_Vx5=hKxqPwRHVnETzAhEev0aHw@mail.gmail.com> (raw) In-Reply-To: <20160112033708.GE6033@dastard> On Mon, Jan 11, 2016 at 7:37 PM, Dave Chinner <david@fromorbit.com> wrote: > > Yes, I heard you the first time, but you haven't acknowledged that > the aio fsync interface is indeed different because it already > exists. What's the problem with implementing an AIO call that we've > advertised as supported for many years now that people are asking us > to implement it? Oh, I don't disagree with that. I think it should be exposed, my point was that that too was not enough. I don't see why you argue. You said "that's not enough". And I jjust said that your expansion wasn't sufficient either, and that I think we should strive to expand things even more. And preferably not in some ad-hoc manner. Expand it to *everything* we can do. > As for a generic async syscall interface, why not just add > IOCB_CMD_SYSCALL that encodes the syscall number and parameters > into the iovec structure and let the existing aio subsystem handle > demultiplexing it and handing them off to threads/workqueues/etc? That would likely be the simplest approach, yes. There's a few arguments against it, though: - doing the indirect system call thing does end up being architecture-specific, so now you do need the AIO code to call into some arch wrapper. Not a huge deal, since the arch wrapper will be pretty simple (and we can have a default one that just returns ENOSYS, so that we don't have to synchronize all architectures) - the aio interface really is horrible crap. Really really. For example, the whole "send signal as a completion model" is so f*cking broken that I really don't want to extend the aio interface too much. I think it's unfixable. So I really think we'd be *much* better off with a new interface entirely - preferably one that allows the old aio interfaces to fall out fairly naturally. Ben mentioned lio_listio() as a reason for why he wanted to extend the AIO interface, but I think it works the other way around: yes, we should look at lio_listio(), but we should look at it mainly as a way to ask ourselves: "can we implement a new aynchronous system call submission model that would also make it possible to implement lio_listio() as a user space wrapper around it". For example, if we had an actual _good_ way to queue up things, you could probably make that "struct sigevent" completion for lio_listio() just be another asynchronous system call at the end of the list - a system call that sends the completion signal. And the aiocb_list[] itself? Maybe those could just be done as normal (individual) aio calls (so that you end up having the aiocb that you can wait on with aio_suspend() etc). But then people who do *not* want the crazy aiocb, and do *not* want some SIGIO or whatever, could just fire off asynchronous system calls without that cruddy interface. So my argument is really that I think it would be better to at least look into maybe creating something less crapulent, and striving to make it easy to make the old legacy interfaces be just wrappers around a more capable model. And hey, it may be that in the end nobody cares enough, and the right thing (or at least the prudent thing) to do is to just pile the crap on deeper and higher, and just add a single IOCB_CMD_SYSCALL indirection entry. So I'm not dismissing that as a solution - I just don't think it's a particularly clean one. It does have the advantage of likely being a fairly simple hack. But it smells like a hack. Linus -- 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-01-12 4:03 UTC|newest] Thread overview: 133+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-01-11 22:06 [PATCH 00/13] aio: thread (work queue) based aio and new aio functionality Benjamin LaHaise 2016-01-11 22:06 ` Benjamin LaHaise 2016-01-11 22:06 ` [PATCH 01/13] signals: distinguish signals sent due to i/o via io_send_sig() Benjamin LaHaise 2016-01-11 22:06 ` Benjamin LaHaise 2016-01-11 22:06 ` Benjamin LaHaise 2016-01-11 22:06 ` [PATCH 02/13] aio: add aio_get_mm() helper Benjamin LaHaise 2016-01-11 22:06 ` Benjamin LaHaise 2016-01-11 22:06 ` Benjamin LaHaise 2016-01-11 22:06 ` [PATCH 03/13] aio: for async operations, make the iter argument persistent Benjamin LaHaise 2016-01-11 22:06 ` Benjamin LaHaise 2016-01-11 22:06 ` Benjamin LaHaise 2016-01-11 22:07 ` [PATCH 04/13] signals: add and use aio_get_task() to direct signals sent via io_send_sig() Benjamin LaHaise 2016-01-11 22:07 ` Benjamin LaHaise 2016-01-11 22:07 ` Benjamin LaHaise 2016-01-11 22:07 ` [PATCH 05/13] fs: make do_loop_readv_writev() non-static Benjamin LaHaise 2016-01-11 22:07 ` Benjamin LaHaise 2016-01-11 22:07 ` Benjamin LaHaise 2016-01-11 22:07 ` [PATCH 06/13] aio: add queue_work() based threaded aio support Benjamin LaHaise 2016-01-11 22:07 ` Benjamin LaHaise 2016-01-11 22:07 ` Benjamin LaHaise 2016-01-11 22:07 ` [PATCH 07/13] aio: enabled thread based async fsync Benjamin LaHaise 2016-01-11 22:07 ` Benjamin LaHaise 2016-01-11 22:07 ` Benjamin LaHaise 2016-01-12 1:11 ` Dave Chinner 2016-01-12 1:11 ` Dave Chinner 2016-01-12 1:20 ` Linus Torvalds 2016-01-12 1:20 ` Linus Torvalds 2016-01-12 2:25 ` Dave Chinner 2016-01-12 2:25 ` Dave Chinner 2016-01-12 2:25 ` Dave Chinner 2016-01-12 2:38 ` Linus Torvalds 2016-01-12 2:38 ` Linus Torvalds 2016-01-12 3:37 ` Dave Chinner 2016-01-12 3:37 ` Dave Chinner 2016-01-12 4:03 ` Linus Torvalds [this message] 2016-01-12 4:03 ` Linus Torvalds 2016-01-12 4:48 ` Linus Torvalds 2016-01-12 4:48 ` Linus Torvalds 2016-01-12 22:50 ` Benjamin LaHaise 2016-01-12 22:50 ` Benjamin LaHaise 2016-01-12 22:50 ` Benjamin LaHaise 2016-01-15 20:21 ` Benjamin LaHaise 2016-01-15 20:21 ` Benjamin LaHaise 2016-01-15 20:21 ` Benjamin LaHaise 2016-01-20 3:59 ` Linus Torvalds 2016-01-20 3:59 ` Linus Torvalds 2016-01-20 3:59 ` Linus Torvalds 2016-01-20 5:02 ` Theodore Ts'o 2016-01-20 5:02 ` Theodore Ts'o 2016-01-20 5:02 ` Theodore Ts'o 2016-01-20 19:59 ` Dave Chinner 2016-01-20 19:59 ` Dave Chinner 2016-01-20 19:59 ` Dave Chinner 2016-01-20 20:29 ` Linus Torvalds 2016-01-20 20:29 ` Linus Torvalds 2016-01-20 20:44 ` Benjamin LaHaise 2016-01-20 20:44 ` Benjamin LaHaise 2016-01-20 20:44 ` Benjamin LaHaise 2016-01-20 21:45 ` Dave Chinner 2016-01-20 21:45 ` Dave Chinner 2016-01-20 21:56 ` Benjamin LaHaise 2016-01-20 21:56 ` Benjamin LaHaise 2016-01-20 21:56 ` Benjamin LaHaise 2016-01-23 4:24 ` Dave Chinner 2016-01-23 4:24 ` Dave Chinner 2016-01-23 4:50 ` Benjamin LaHaise 2016-01-23 4:50 ` Benjamin LaHaise 2016-01-23 4:50 ` Benjamin LaHaise 2016-01-23 22:22 ` Dave Chinner 2016-01-23 22:22 ` Dave Chinner 2016-01-23 22:22 ` Dave Chinner 2016-01-20 23:07 ` Linus Torvalds 2016-01-23 4:39 ` Dave Chinner 2016-01-23 4:39 ` Dave Chinner 2016-01-23 4:39 ` Dave Chinner 2016-03-14 17:17 ` aio openat " Benjamin LaHaise 2016-03-14 17:17 ` Benjamin LaHaise 2016-03-20 1:20 ` Linus Torvalds 2016-03-20 1:20 ` Linus Torvalds 2016-03-20 1:26 ` Al Viro 2016-03-20 1:26 ` Al Viro 2016-03-20 1:26 ` Al Viro 2016-03-20 1:45 ` Linus Torvalds 2016-03-20 1:45 ` Linus Torvalds 2016-03-20 1:45 ` Linus Torvalds 2016-03-20 1:55 ` Al Viro 2016-03-20 1:55 ` Al Viro 2016-03-20 2:03 ` Linus Torvalds 2016-03-20 2:03 ` Linus Torvalds 2016-03-20 2:03 ` Linus Torvalds 2016-01-20 21:57 ` Dave Chinner 2016-01-20 21:57 ` Dave Chinner 2016-01-20 21:57 ` Dave Chinner 2016-01-22 15:41 ` Andres Freund 2016-01-22 15:41 ` Andres Freund 2016-01-12 22:59 ` Andy Lutomirski 2016-01-12 22:59 ` Andy Lutomirski 2016-01-12 22:59 ` Andy Lutomirski 2016-01-14 9:19 ` Paolo Bonzini 2016-01-14 9:19 ` Paolo Bonzini 2016-01-14 9:19 ` Paolo Bonzini 2016-01-12 1:30 ` Benjamin LaHaise 2016-01-12 1:30 ` Benjamin LaHaise 2016-01-12 1:30 ` Benjamin LaHaise 2016-01-22 15:31 ` Andres Freund 2016-01-22 15:31 ` Andres Freund 2016-01-22 15:31 ` Andres Freund 2016-01-11 22:07 ` [PATCH 08/13] aio: add support for aio poll via aio thread helper Benjamin LaHaise 2016-01-11 22:07 ` Benjamin LaHaise 2016-01-11 22:07 ` [PATCH 09/13] aio: add support for async openat() Benjamin LaHaise 2016-01-11 22:07 ` Benjamin LaHaise 2016-01-11 22:07 ` Benjamin LaHaise 2016-01-12 0:22 ` Linus Torvalds 2016-01-12 0:22 ` Linus Torvalds 2016-01-12 1:17 ` Benjamin LaHaise 2016-01-12 1:17 ` Benjamin LaHaise 2016-01-12 1:17 ` Benjamin LaHaise 2016-01-12 1:45 ` Chris Mason 2016-01-12 1:45 ` Chris Mason 2016-01-12 1:45 ` Chris Mason 2016-01-12 9:53 ` Ingo Molnar 2016-01-12 9:53 ` Ingo Molnar 2016-01-12 9:53 ` Ingo Molnar 2016-01-11 22:07 ` [PATCH 10/13] aio: add async unlinkat functionality Benjamin LaHaise 2016-01-11 22:07 ` Benjamin LaHaise 2016-01-11 22:07 ` Benjamin LaHaise 2016-01-11 22:07 ` [PATCH 11/13] mm: enable __do_page_cache_readahead() to include present pages Benjamin LaHaise 2016-01-11 22:07 ` Benjamin LaHaise 2016-01-11 22:07 ` [PATCH 12/13] aio: add support for aio readahead Benjamin LaHaise 2016-01-11 22:07 ` Benjamin LaHaise 2016-01-11 22:08 ` [PATCH 13/13] aio: add support for aio renameat operation Benjamin LaHaise 2016-01-11 22:08 ` Benjamin LaHaise 2016-01-11 22:08 ` Benjamin LaHaise
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='CA+55aFyLb8scNSYb19rK4iT_Vx5=hKxqPwRHVnETzAhEev0aHw@mail.gmail.com' \ --to=torvalds@linux-foundation.org \ --cc=akpm@linux-foundation.org \ --cc=bcrl@kvack.org \ --cc=david@fromorbit.com \ --cc=linux-aio@kvack.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=viro@zeniv.linux.org.uk \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.