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 X-Spam-Level: X-Spam-Status: No, score=-7.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2063C433F5 for ; Fri, 10 Sep 2021 03:22:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9B20661074 for ; Fri, 10 Sep 2021 03:22:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230004AbhIJDXn (ORCPT ); Thu, 9 Sep 2021 23:23:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50436 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229461AbhIJDXm (ORCPT ); Thu, 9 Sep 2021 23:23:42 -0400 Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9BEE1C061574 for ; Thu, 9 Sep 2021 20:22:32 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id b4so603204ilr.11 for ; Thu, 09 Sep 2021 20:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=EvIKhcEAdqIX2oPTeV2qcqjuPBERBJ9PR89hwHrrM/g=; b=zo7SZOF+zEI1ym97HonQU2W1Yus3eovW6l82Jvq6a0nxgBIH9mrs8aus1GjvBiXqEj fmjTSd9kNsEzETkPJW90TgsV4yjffghQHrgWH3+5lN4b0liLQvP8+OjSPmsKhdO/pOle 57HRdc9jqClJVs8LsmUB5rMq1e6NNItgKEeVfAR9ekzN6ZJnObKuDesZnhiA/9JLHPO+ f5O44vMJtLZalIE7eQq/TuLp7+sTyKFbD1ZGXGX8qPNpPEywVqJ1gC5Yy2ORXfM8aht6 INEYNHI7LpUo+J0BxONN636yJuBRO07yCwYb4SaXLoE5P3V/jk3nmdhhM7k25T8674Al qy7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EvIKhcEAdqIX2oPTeV2qcqjuPBERBJ9PR89hwHrrM/g=; b=CiSzddD2BlRRPQXHLLDTkO8f4Cb3bh2pl8lHiJkfxdXbh3IL03mPpJUfRHU+bbSkC6 wy5qG2DtRy0Oi1h3EDcL5+NKACkbjFml4UTEkmRW5RivV180WH11GjKiWxcgjYD+nqM4 EsyNqls3FcAts+HlIPbjgWCBRXJGVnwCIjnUHPqRN6v7qYfqsRwZrmeAXe7zmeE7Gwhk n8c0ZLK/TLvjw5XsXI6geF3SKj6EAniXkw9gxe+d6z+ZmxEu9czFz3JuVIT0ejmk4r/9 tvURnLwQG4mzYlekWnHbswUjLHN4Hrf5I7rkG4+llCf3f8o80s+ZAGr9l8f1DeduQYoW m0AQ== X-Gm-Message-State: AOAM532oQvbOw1TsBamKN+J+H2yWjqGrGhf1s9cdYyMp4o4iQg9qIOra gcUD7QLhB79ifQp2tQVxHtTzkQ== X-Google-Smtp-Source: ABdhPJzmZ236OO7DLFvFfRKWpAeT2W3uSVeBClLTwXMD2qRNpAMlCOCiEfrguqYJEyaD38nPELeMtg== X-Received: by 2002:a05:6e02:1074:: with SMTP id q20mr4867076ilj.204.1631244151770; Thu, 09 Sep 2021 20:22:31 -0700 (PDT) Received: from [192.168.1.116] ([66.219.217.159]) by smtp.gmail.com with ESMTPSA id t14sm1858429ilu.67.2021.09.09.20.22.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Sep 2021 20:22:31 -0700 (PDT) Subject: Re: [git pull] iov_iter fixes To: Al Viro Cc: Linus Torvalds , Pavel Begunkov , Linux Kernel Mailing List , linux-fsdevel References: <5971af96-78b7-8304-3e25-00dc2da3c538@kernel.dk> From: Jens Axboe Message-ID: <9ae5f07f-f4c5-69eb-bcb1-8bcbc15cbd09@kernel.dk> Date: Thu, 9 Sep 2021 21:22:30 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/9/21 9:11 PM, Al Viro wrote: > On Thu, Sep 09, 2021 at 09:05:13PM -0600, Jens Axboe wrote: >> On 9/9/21 8:57 PM, Al Viro wrote: >>> On Thu, Sep 09, 2021 at 03:19:56PM -0600, Jens Axboe wrote: >>> >>>> Not sure how we'd do that, outside of stupid tricks like copy the >>>> iov_iter before we pass it down. But that's obviously not going to be >>>> very efficient. Hence we're left with having some way to reset/reexpand, >>>> even in the presence of someone having done truncate on it. >>> >>> "Obviously" why, exactly? It's not that large a structure; it's not >>> the optimal variant, but I'd like to see profiling data before assuming >>> that it'll cause noticable slowdowns. >> >> It's 48 bytes, and we have to do it upfront. That means we'd be doing it >> for _all_ requests, not just when we need to retry. As an example, current >> benchmarks are at ~4M read requests per core. That'd add ~200MB/sec of >> memory traffic just doing this copy. > > Umm... How much of that will be handled by cache? Depends? And what if the iovec itself has been modified in the middle? We'd need to copy that whole thing too. It's just not workable as a solution. >> Besides, I think that's moot as there's a better way. > > I hope so, but I'm afraid that "let's reload from userland on e.g. short > reads" is not better - there's a plenty of interesting corner cases you > need to handle with that. As long as we're still in the context of the submission, it is tractable provided we import it like we did originally. -- Jens Axboe