Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp315867pxu; Fri, 11 Dec 2020 03:05:35 -0800 (PST) X-Google-Smtp-Source: ABdhPJz+EZ1MBsIpfrNChzB1fdsyd0M6nO7QkrLXN4esAZ4Z83uKAt/K9tKX0dFm2AGWES5+ZTa5 X-Received: by 2002:a05:6402:48d:: with SMTP id k13mr11092255edv.92.1607684735307; Fri, 11 Dec 2020 03:05:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607684735; cv=none; d=google.com; s=arc-20160816; b=mTWO7EkBlLCnTEjMF151xorLVGV/NNDI4sAsrN3okkk9dGLxgcUYKFOaTgjp84/xEb MY0o/2yC8qFh8f3yjkywZAQxRekrb0mvJd39L7UYurlZp1/gfGu+EDePAirXZBzIGJ3A 5cBgRKC+47Xthf7tqp0dwfMphT+kIjm/jOu9WbinTBoWh0Btd8HgimSNWs9X0pFQWJgM Vi9f2xncen/0t3paA/KFNij1IbD8cptfJtIIOjghyCKbB2qTcesIYQv8dyT4UKBjlq33 ckCp9fp+pJRXfeRi8o/faoHdSz1wThtUbCdDJvnn1Y5uIaktsFlvUeI+m97TOpo1UHTt g0yQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=OZOyUbA7rCQDn2EtJNYTjj2GzTu69ZgsxFvWqfh2HwM=; b=KihGVdCXHLJMXa2Mb/rbCt3/YQWZ9S6HHbf16bea/NNQDDvTQm+AGCcuSBsmUhguDn JqnSUQ1qyVdvxJ2aXSL3GOO4qizzLKXBw+fA+LgkA+B0LFYG0XFaN04WcxusCrnHtt5V nb5DLRNUvWF8f3bAxhsHJV4ZOFE21qA8hIKZ9wmQ2OxRUXxrNF79eYWf7nThZjrYBku8 aUCCET5V9zgP+P2dG18Bff3onDLgT7ziH5hdpvH89UrhRps04jMA1Jod9Cls+A3xbp3O b/0D1uTj90sJNFB/hQT2Xg0btPOnzr2eYxf6vbEf5QNqc2YziTx9ynU4jIOoTkOem8Vh OC7g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k16si4521393edr.236.2020.12.11.03.05.12; Fri, 11 Dec 2020 03:05:35 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389610AbgLKBcQ (ORCPT + 99 others); Thu, 10 Dec 2020 20:32:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38144 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389890AbgLKBbn (ORCPT ); Thu, 10 Dec 2020 20:31:43 -0500 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE565C0613D6; Thu, 10 Dec 2020 17:31:03 -0800 (PST) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1knXGn-000SL0-2o; Fri, 11 Dec 2020 01:30:53 +0000 Date: Fri, 11 Dec 2020 01:30:53 +0000 From: Al Viro To: Linus Torvalds Cc: David Howells , Pavel Begunkov , Matthew Wilcox , Jens Axboe , linux-fsdevel , linux-block , Linux Kernel Mailing List Subject: Re: [PATCH 01/29] iov_iter: Switch to using a table of operations Message-ID: <20201211013053.GA107834@ZenIV.linux.org.uk> References: <160596800145.154728.7192318545120181269.stgit@warthog.procyon.org.uk> <160596801020.154728.15935034745159191564.stgit@warthog.procyon.org.uk> 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-kernel@vger.kernel.org On Sat, Nov 21, 2020 at 10:21:17AM -0800, Linus Torvalds wrote: > So I think conceptually this is the right thing to do, but I have a > couple of worries: > > - do we really need all those different versions? I'm thinking > "iter_full" versions in particular. They I think the iter_full version > could just be wrappers that call the regular iter thing and verify the > end result is full (and revert if not). No? Umm... Not sure - iov_iter_revert() is not exactly light. OTOH, it's on a slow path... Other variants: * save local copy, run of normal variant on iter, then copy the saved back on failure * make a local copy, run the normal variant in _that_, then copy it back on success. Note that the entire thing is 5 words, and we end up reading all of them anyway, so I wouldn't bet which variant ends up being faster - that would need testing to compare. I would certainly like to get rid of the duplication there, especially if we are going to add copy_to_iter_full() and friends (there are use cases for those). > - I worry a bit about the indirect call overhead and spectre v2. > > So yeah, it would be good to have benchmarks to make sure this > doesn't regress for some simple case. > > Other than those things, my initial reaction is "this does seem cleaner". It does seem cleaner, all right, but that stuff is on fairly hot paths. And I didn't want to mix the overhead of indirect calls into the picture, so it turned into cascades of ifs with rather vile macros to keep the size down. It looks like the cost of indirects is noticable. OTOH, there are other iov_iter patches floating around, hopefully getting better code generation. Let's see how much do those give and if they win considerably more than those several percents, revisit this series.