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 22B5AC05027 for ; Fri, 10 Feb 2023 06:58:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231403AbjBJG6R (ORCPT ); Fri, 10 Feb 2023 01:58:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231313AbjBJG6N (ORCPT ); Fri, 10 Feb 2023 01:58:13 -0500 Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 08F695AB35 for ; Thu, 9 Feb 2023 22:57:51 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id v23so5572958plo.1 for ; Thu, 09 Feb 2023 22:57:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=1U8Y/0tbcD9B+rFGh6iJhmikTGHljyJ4FQw+gensxqM=; b=4Z1SYdNbd8WuXmbNbPTp5CPsq+GgaHbcr8G8z8Vf2uXbpsOUdr/18311fSoj/DAvdM vKD8kJ4v+dlInCvARG32DgUVW8yzfAhNkAyg4PrXHQ8xbnM6qm00vXAjizV3lv9K0Sf/ yhmZ9myipWzdAp3N3yBHfaKYQ0cJ0ZZ9R3JLCAc8crow8cakcI10UvY9qknPlyW1qW2Z DMKFP+tHUhN2tmNEIcIcgczDV7s8cjMmG51ixCnGXX2nvFqjCTjT9YADasror/vi7CU8 10fPbGPPQUto5nhsZhX9kHLpIDYok04ij/5sDWe8+1g8aQUBeNpw+SaOrYegc5uSMILw cGxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=1U8Y/0tbcD9B+rFGh6iJhmikTGHljyJ4FQw+gensxqM=; b=vPERz2EQZKlqyNRVqXJsB5UzsdaL8YMpYBf/JhS5zzIG/RKVq276RkedMEj3ieA8To TJaQosoYo2c/nF7Cs0SIa1MJtxx4EgM8Chk1g/Wrbx12KZjNHwGg339oKFs8VPdM6bfl YfavPEdmW+JkCVVl5qsE4FqeRBIUqP+PFei6y1tmsGzUQlGu6jLWAV1CK31umaDKKnDR xnEDjv3YpNgiS6zWogBgm1Vt0ylK2z0+xkNpfRa/kUBABrlxHefvyGnqTRqTxl9aiPMS mE2d6+S7LxkXMx1vQUr95b2LLbkSeGHTm6nJSNHKHr0WP0V0wj1ajGMPHRudbzCBJ81p zJcg== X-Gm-Message-State: AO0yUKWxMl9ocMFqY8TNVH5WgHlP4zaSUUfzhCHP63G9RWkQ2Ydu2P2x avgT91IIsJOecUfiJHCW+VF+Gg== X-Google-Smtp-Source: AK7set9t6gqJxoHDZIn5ha1EJDlZJueE1TdlQVqKbhBYcp7XjUdmkxQUWlM78CqsSipLc15u/SU+4w== X-Received: by 2002:a05:6a21:3613:b0:bc:30aa:8a6d with SMTP id yg19-20020a056a21361300b000bc30aa8a6dmr11239502pzb.2.1676012270527; Thu, 09 Feb 2023 22:57:50 -0800 (PST) Received: from dread.disaster.area (pa49-181-4-128.pa.nsw.optusnet.com.au. [49.181.4.128]) by smtp.gmail.com with ESMTPSA id i76-20020a636d4f000000b004fb171df68fsm2298927pgc.7.2023.02.09.22.57.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Feb 2023 22:57:50 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1pQNLv-00DXUC-AP; Fri, 10 Feb 2023 17:57:47 +1100 Date: Fri, 10 Feb 2023 17:57:47 +1100 From: Dave Chinner To: Matthew Wilcox Cc: Linus Torvalds , Stefan Metzmacher , Jens Axboe , linux-fsdevel , Linux API Mailing List , io-uring , "linux-kernel@vger.kernel.org" , Al Viro , Samba Technical Subject: Re: copy on write for splice() from file to pipe? Message-ID: <20230210065747.GD2825702@dread.disaster.area> References: <0cfd9f02-dea7-90e2-e932-c8129b6013c7@samba.org> <20230210021603.GA2825702@dread.disaster.area> <20230210040626.GB2825702@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 10, 2023 at 04:44:41AM +0000, Matthew Wilcox wrote: > On Fri, Feb 10, 2023 at 03:06:26PM +1100, Dave Chinner wrote: > > So while I was pondering the complexity of this and watching a great > > big shiny rocket create lots of heat, light and noise, it occurred > > That was kind of fun :) > > to me that we already have a mechanism for preventing page cache > > data from being changed while the folios are under IO: > > SB_I_STABLE_WRITES and folio_wait_stable(). > > I thought about bringing that up, but it's not quite right. That works > great for writeback, but it only works for writeback. We'd need to track > another per-folio counter ... it'd be like the page pinning kerfuffle, > only worse. Hmmm - I didn't think of that. It needs the counter because the "stable request" is per folio reference state, not per folio state, right? And the single flag works for writeback because we can only have one writeback context in progress at a time? Yeah, not sure how to deal with that easily. > And for such a rare thing it seems like a poor use of 32 > bits of per-page state. Maybe, but zero copy file data -> network send is a pretty common workload. Web servers, file servers, remote backup programs, etc. Having files being written whilst others are reading them is not as common, but that does happen in a wide variety of shared file server environments. Regardless, I just had a couple of ideas - it they don't work so be it. > Not to mention that you can effectively block > all writes to a file for an indefinite time by splicing pages to a pipe > that you then never read from. No, I wasn't suggesting that we make pages in transit stable - they only need to be stable while the network stack requires them to be stable.... Cheers, Dave. -- Dave Chinner david@fromorbit.com