From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760894AbcALDhp (ORCPT ); Mon, 11 Jan 2016 22:37:45 -0500 Received: from ipmail04.adl6.internode.on.net ([150.101.137.141]:35531 "EHLO ipmail04.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760409AbcALDhM (ORCPT ); Mon, 11 Jan 2016 22:37:12 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CwDQC0c5RWPGu7LXleKAECgw+BP4Jig36BeaApAQEBAQEBBotdhT2EB4YJAgIBAQKBKU0BAQEBAQEHAQEBAUE/QRIBg2EBAQQ6HCMQCAMYCSUPBSUDBxoTiC2/bAEBAQEGAgEgGYV1hUeIIoEbBZcTjVCPBY5RhQIqNIQvSwSBRwEBAQ Date: Tue, 12 Jan 2016 14:37:08 +1100 From: Dave Chinner To: Linus Torvalds Cc: Benjamin LaHaise , linux-aio@kvack.org, linux-fsdevel , Linux Kernel Mailing List , Linux API , linux-mm , Alexander Viro , Andrew Morton Subject: Re: [PATCH 07/13] aio: enabled thread based async fsync Message-ID: <20160112033708.GE6033@dastard> References: <80934665e0dd2360e2583522c7c7569e5a92be0e.1452549431.git.bcrl@kvack.org> <20160112011128.GC6033@dastard> <20160112022548.GD6033@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 11, 2016 at 06:38:15PM -0800, Linus Torvalds wrote: > On Mon, Jan 11, 2016 at 6:25 PM, Dave Chinner wrote: > > > > That's a different interface. > > So is openat. So is readahead. > > My point is that this idiotic "let's expose special cases" must end. > It's broken. It inevitably only exposes a subset of what different > people would want. > > Making "aio_read()" and friends a special interface had historical > reasons for it. But expanding willy-nilly on that model does not. 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? 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 was we get contexts, events, signals, completions, cancelations, etc from the existing infrastructure, and there's really only a dispatch/collection layer that needs to be added? If we then provide the userspace interface via the libaio library to call the async syscalls with an AIO context handle, then there's little more that needs to be done to support just about everything as an async syscall... Cheers, Dave. -- Dave Chinner david@fromorbit.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 12 Jan 2016 14:37:08 +1100 From: Dave Chinner To: Linus Torvalds Cc: Benjamin LaHaise , linux-aio@kvack.org, linux-fsdevel , Linux Kernel Mailing List , Linux API , linux-mm , Alexander Viro , Andrew Morton Subject: Re: [PATCH 07/13] aio: enabled thread based async fsync Message-ID: <20160112033708.GE6033@dastard> References: <80934665e0dd2360e2583522c7c7569e5a92be0e.1452549431.git.bcrl@kvack.org> <20160112011128.GC6033@dastard> <20160112022548.GD6033@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: On Mon, Jan 11, 2016 at 06:38:15PM -0800, Linus Torvalds wrote: > On Mon, Jan 11, 2016 at 6:25 PM, Dave Chinner wrote: > > > > That's a different interface. > > So is openat. So is readahead. > > My point is that this idiotic "let's expose special cases" must end. > It's broken. It inevitably only exposes a subset of what different > people would want. > > Making "aio_read()" and friends a special interface had historical > reasons for it. But expanding willy-nilly on that model does not. 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? 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 was we get contexts, events, signals, completions, cancelations, etc from the existing infrastructure, and there's really only a dispatch/collection layer that needs to be added? If we then provide the userspace interface via the libaio library to call the async syscalls with an AIO context handle, then there's little more that needs to be done to support just about everything as an async syscall... Cheers, Dave. -- Dave Chinner david@fromorbit.com -- 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