From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1E28BC433EF for ; Sun, 22 May 2022 12:21:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235275AbiEVMVf (ORCPT ); Sun, 22 May 2022 08:21:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45680 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229928AbiEVMVd (ORCPT ); Sun, 22 May 2022 08:21:33 -0400 Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [IPv6:2607:5300:60:148a::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ACBF912D33 for ; Sun, 22 May 2022 05:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=TRaJ+WxtTKiWzQ2HHXgCSRjcxXfzUt+lZEwV5j4uP+8=; b=swNRVIOWC9fR6rk8M5b3WSVvIk BFRfT779TH+FURGy7G5nMLv68E255YxMyV4mzytdpWUi3oUKdZHdbTHyGyteyAGeozdY8HVDGQiuv zopzZ3qw2fM3AhL/DwPO6Af90Fns96uY3RrkW0E3WlNmq/Ow3yWMfkduEXitMMa/CzHRPqKOY6vep 8ZwxO7bfg4d9fplXunqY0/cC26Hk8wljFA5DiC8ewMGnaLrUs1eCuR74hLyWNB8MNBChUOBEuJ7E1 XZvWKf5uQJ2eJAuMn7Tgu73YvnzlyMkhFAahR9u36LD+si95jLRuA7DLQ732AzUK0nlebRc0Tu1aR 4qcZwPNQ==; Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nskaO-00HApY-9Y; Sun, 22 May 2022 12:21:28 +0000 Date: Sun, 22 May 2022 12:21:28 +0000 From: Al Viro To: Matthew Wilcox Cc: Christoph Hellwig , Jens Axboe , linux-fsdevel@vger.kernel.org Subject: Re: [RFC] what to do with IOCB_DSYNC? Message-ID: References: <20210621142235.GA2391@lst.de> <20210621143501.GA3789@lst.de> <70b5e4a8-1daa-dc75-af58-9d82a732a6be@kernel.dk> <20220522074508.GB15562@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Sun, May 22, 2022 at 12:15:59PM +0100, Matthew Wilcox wrote: > On Sun, May 22, 2022 at 10:36:00AM +0000, Al Viro wrote: > > On Sun, May 22, 2022 at 11:23:43AM +0100, Matthew Wilcox wrote: > > > On Sun, May 22, 2022 at 09:45:09AM +0200, Christoph Hellwig wrote: > > > > On Sat, May 21, 2022 at 04:14:07PM -0600, Jens Axboe wrote: > > > > > Then we're almost on par, and it looks like we just need to special case > > > > > iov_iter_advance() for the nr_segs == 1 as well to be on par. This is on > > > > > top of your patch as well, fwiw. > > > > > > > > > > It might make sense to special case the single segment cases, for both > > > > > setup, iteration, and advancing. With that, I think we'll be where we > > > > > want to be, and there will be no discernable difference between the iter > > > > > paths and the old style paths. > > > > > > > > A while ago willy posted patches to support a new ITER type for direct > > > > userspace pointer without iov. It might be worth looking through the > > > > archives and test that. > > > > > > https://lore.kernel.org/linux-fsdevel/Yba+YSF6mkM%2FGYlK@casper.infradead.org/ > > > > Direct kernel pointer, surely? And from a quick look, > > iov_iter_is_kaddr() checks for the wrong value... > > Indeed. I didn't test it; it was a quick patch to see if the idea was > worth pursuing. Neither you nor Christoph thought so at the time, so > I dropped it. if there are performance improvements to be had from > doing something like that, it's a more compelling idea than just "Hey, > this removes a few lines of code and a bit of stack space from every > caller". Depends; I rather doubt that it would be useful for kvec case, but iovec one like that... The only thing that worries me here is the code generation for the cascades of ifs in lib/iov_iter.c - that'd need profiling. And it's orthogonal to the overhead in new_sync_{read,write}(), obviously.