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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 808F9D42BBA for ; Tue, 12 Nov 2024 18:14:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 017606B00A0; Tue, 12 Nov 2024 13:14:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F0ABF6B00B1; Tue, 12 Nov 2024 13:14:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DAB256B00ED; Tue, 12 Nov 2024 13:14:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id BA2DF6B00A0 for ; Tue, 12 Nov 2024 13:14:35 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E55B81204E3 for ; Tue, 12 Nov 2024 18:14:34 +0000 (UTC) X-FDA: 82778242302.15.D0BDAF3 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf29.hostedemail.com (Postfix) with ESMTP id 40228120028 for ; Tue, 12 Nov 2024 18:13:36 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=G2QRstQb; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf29.hostedemail.com: domain of bfoster@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731435186; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=NmxhVs+P1hJWoZYSTyfdVSHjqXEZNLNo4iVdoO1zihw=; b=S777xjCE0GC/0UAE0FR+wUUT1//4N6bP1q+V1h8oI+d8fz5/IqV3orlsuatg2OyK92cYcC F888PlOa2x5rBm3Avx7bTI+oLtSxM96RepcaqORifC+aHPPWzuev04iZfznw/IxEtoPk4/ 84ae3S4l8BAe46GgIvHGeiRc81sN0cU= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=G2QRstQb; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf29.hostedemail.com: domain of bfoster@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731435186; a=rsa-sha256; cv=none; b=5iMLkQeqk2cn93V3ZDFP3XZ3wNRXI1nHQrgX/4aMemsVekkj15cx8GX+RUiy780XMzRBpZ rlucVq1csc2d6/o5DC+HXyZtyJPfkkgbOsojLgH6lOPFFyql+ShDOEsvDeq3Q5Y61qglbH c1ODfsN9Sz2i7a15BKoxjXAPI4vKRqA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1731435272; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NmxhVs+P1hJWoZYSTyfdVSHjqXEZNLNo4iVdoO1zihw=; b=G2QRstQbkKmfZI5SzmDs22aIIfRJB1+YNX7W1oJn7WircDEChDUlXxDsG7vQrsS5eULwys BbkiM93TdnyFPrnoopRFUKwbG+PVpWkfuR4yeWw/C7CECv+ZibG1Z+bAJOls5KMl70b+67 U3NnKVtRz9FEsx0W3RxjtU4mvNftNJY= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-441-542WbpeqPuywkE7leFyq5g-1; Tue, 12 Nov 2024 13:14:26 -0500 X-MC-Unique: 542WbpeqPuywkE7leFyq5g-1 X-Mimecast-MFC-AGG-ID: 542WbpeqPuywkE7leFyq5g Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 5F77419560B1; Tue, 12 Nov 2024 18:14:17 +0000 (UTC) Received: from bfoster (unknown [10.22.80.120]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 238491956086; Tue, 12 Nov 2024 18:14:14 +0000 (UTC) Date: Tue, 12 Nov 2024 13:15:47 -0500 From: Brian Foster To: Jens Axboe Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, hannes@cmpxchg.org, clm@meta.com, linux-kernel@vger.kernel.org, willy@infradead.org, kirill@shutemov.name, linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org Subject: Re: [PATCH 13/16] iomap: make buffered writes work with RWF_UNCACHED Message-ID: References: <20241111234842.2024180-1-axboe@kernel.dk> <20241111234842.2024180-14-axboe@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 40228120028 X-Stat-Signature: sakd3kfs5a3w4armhok9qkqec5bq3bwf X-HE-Tag: 1731435216-536139 X-HE-Meta: U2FsdGVkX18FNuMazmRj0+Ovabb3zXz8b/ytHtCuJ6/1WqNz4bH5QGLqaNeJp/VGFcofccPQydoIb8cOFudfOFIo97N5jvyMBkFtkREDSdAl+ZlLDPevGON70qtx/VZsPAJZ3D1RCqbpKyoCuPH4w3cyuZ0Y+BPqv8Cn6vrxVhB6wVCCfD4CaJxYbJZPBa79rjfCPiVLNSysg7tn5WASBAQ0+91n20gS29VSBWPbW/4t8BeyC4zpRcikoos9pPS8rBQuznu3yhTa1vZL4JOkjiqOYCsmXzhGh7yacQFFIBc9aJ1+KivlwsAd5vOePRWcciTJhKOU+3g71q24pHjRy28wYLBbCr9LS/yEme/HtzQ/n4BO+eUzj9ZVGODrN79Cd6ze2NqxPg5MsLZQKjP/nue0RM+YDfaddpAmsSM+vEK4h99lqOFSuapbQTSKsNmZeLeHemCtpHXbY81qvy7j3vkUhMo69NEVNc0x4Rvk+82vTNm3H23G2nSbqQu3VQa3ZR7/wgrnb87/Gychm7vxX6iyLuQow4cTO1Rj/wCs0jjn+wHchLrQUzlo4ZoB6o/ub0ffj/6KNavDWp7xSXpKwfKnXWc51a7A2VOkjQuSftwm8fKENPxFaNi4ZuKa/CL09zkII3gbvVVUKGUokjWOlv2koMogAigds0s7duyZ/riWIBo+gvqYpbIb2o9v1kidjAe9UPeZDUgkL7Go8Vts34bDylYLIS2EzO9fsdeSL5oaURQmv2cF0zZYPrCCeNLGP//WRkYnq6/AomH12bVT4iGNJ++PrejFC+n65ex3QK89PeTgOUHALUxxsr9ZHGm98m3S/dT7kQzW15k2w2E7talwUe3K5JDAa6ExOYfCEl5wBT8m2QJCOJ2klP5rRLR22jJdSruaHeVACFoiPapy4JorQ+3p3+TRRL39DBOPkHdy1KahI8t7bdWH9La83UQSruoF25uJKsO0yP0OPV2 dNE7PU2d W3U+Fpup6MqxLLSV6iPmnawtghIYvDHu6neU9r4b33eBM+PN5w9qRk52liHnoylApR5yyNQFK1OpHq1y6Ofz1uinMRfGtvF5IGn5beU0DmjBlX3sWS2Q3tjsHOc5f9YAQ3PvXGPLfSqoat9dlTgHEfF5Njq9xs8h+9fEiJrEf7Ma2v5wH+SRFbYvOYR8LUykOKrPnW0LrHZIDIQwwrD6kri7d9u08vXRCdZfvXZMpmitJtCtabx3ZjmOSXMWajXnhtpyJboMEXf2czxm1M3OkXso/KW7zjfD30/BuiAMURI1p0SxV8MngBBmKEm6D3x6ZOPVJms0jI2cAkCSh3BcbcuCBcRZbNiOxfwbf6k4awwlNSaXqaKJIUJMxK6jBAQI7ryqUgw8fU0ZB+zSab0bUibVTgg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Nov 12, 2024 at 10:16:10AM -0700, Jens Axboe wrote: > On 11/12/24 9:37 AM, Brian Foster wrote: > > On Mon, Nov 11, 2024 at 04:37:40PM -0700, Jens Axboe wrote: > >> Add iomap buffered write support for RWF_UNCACHED. If RWF_UNCACHED is > >> set for a write, mark the folios being written with drop_writeback. Then > > > > s/drop_writeback/uncached/ ? > > Ah indeed, guess that never got changed. Thanks, will fix that in the > commit message. > > > BTW, this might be getting into wonky "don't care that much" territory, > > but something else to be aware of is that certain writes can potentially > > change pagecache state as a side effect outside of the actual buffered > > write itself. > > > > For example, xfs calls iomap_zero_range() on write extension (i.e. pos > > > isize), which uses buffered writes and thus could populate a pagecache > > folio without setting it uncached, even if done on behalf of an uncached > > write. > > > > I've only made a first pass and could be missing some details, but IIUC > > I _think_ this means something like writing out a stream of small, > > sparse and file extending uncached writes could actually end up behaving > > more like sync I/O. Again, not saying that's something we really care > > about, just raising it in case it's worth considering or documenting.. > > No that's useful info, I'm not really surprised that there would still > be cases where UNCACHED goes unnoticed. In other words, I'd be surprised > if the current patches for eg xfs/ext4 cover all the cases where new > folios are created and should be marked as UNCACHED of IOCB_UNCACHED is > set in the iocb. > > I think those can be sorted out or documented as we move forward. > UNCACHED is really just a hint - the kernel should do its best to not > have permanent folios for this IO, but there are certainly cases where > it won't be honored if you're racing with regular buffered IO or mmap. > For the case above, sounds like we could cover that, however, and > probably should. > Ok. I suppose you could plumb the iocb state through the zero range call as well, but given the description/semantics I wouldn't blame you if you wanted to leave that for a followon improvement. Thanks for the explanation. Brian > -- > Jens Axboe >