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 106EBC64ED8 for ; Fri, 24 Feb 2023 20:58:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7554E6B0078; Fri, 24 Feb 2023 15:58:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 705556B007B; Fri, 24 Feb 2023 15:58:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F40E6B007D; Fri, 24 Feb 2023 15:58:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 50F7A6B0078 for ; Fri, 24 Feb 2023 15:58:28 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 25739A0155 for ; Fri, 24 Feb 2023 20:58:28 +0000 (UTC) X-FDA: 80503398696.12.64DD4B4 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf17.hostedemail.com (Postfix) with ESMTP id 0167B40004 for ; Fri, 24 Feb 2023 20:58:25 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=CMrjuuxw; spf=pass (imf17.hostedemail.com: domain of dhowells@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dhowells@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677272306; 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=IRX7slzsj7oP9EoAKocW7fCHED6Bws5rQl0DCvHnUe0=; b=6mQcqI1Ts80ud2sS9wl6BK+TiJb7w/un9/wrWhiQCn7m2NAUX7q8vmnHIY5Z5HZK/KXW6y iU2q8d3KuvVcj4mxNDYia4exG+TIlwS5CaKmCQpc/Ab/CyqMfJnzNubEEwyb/+w3ShEytr 9vjVNjb2SrgafzaMxRGnmTPDCCs/lTo= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=CMrjuuxw; spf=pass (imf17.hostedemail.com: domain of dhowells@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dhowells@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677272306; a=rsa-sha256; cv=none; b=XOm/iHkDQi0/SuyRwFcVsCSsHvA8TN30Erh0txaW1bKGDBXzLboUzpiCNB3862VMypjdZe yz8DD/CgtG3p7SrqdcEY2DgjhCtEndWzfVDRAHFK7mF83IvxGWkWCmRRhD6beu2s2a11b4 qu1YicJALhFsuYw7KWh5L7cLamy31O4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677272305; 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=IRX7slzsj7oP9EoAKocW7fCHED6Bws5rQl0DCvHnUe0=; b=CMrjuuxwyBAItveJuCWEZGOuskbuKGWvaQrLpCELyZH8yoHmU42CASt6CyencWW+/ro7y9 VoWL1NO+wF59hNqbpYGGoHL53ByIyw/TFtrlZqfT3nt17R/SA3vcbmuzQ/f0fOlKCrLHej ySDOTNA+v8x+WYPckZmNH1rLEe2+3xY= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-457-DJUjrUgEMh-kLslfuqIpSg-1; Fri, 24 Feb 2023 15:58:21 -0500 X-MC-Unique: DJUjrUgEMh-kLslfuqIpSg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0E6D2811E9C; Fri, 24 Feb 2023 20:58:21 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.33.36.18]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6618CC15BA0; Fri, 24 Feb 2023 20:58:19 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: References: <2134430.1677240738@warthog.procyon.org.uk> <2009825.1677229488@warthog.procyon.org.uk> <20230220135225.91b0f28344c01d5306c31230@linux-foundation.org> <2213409.1677249075@warthog.procyon.org.uk> <2385089.1677258941@warthog.procyon.org.uk> <2390711.1677269637@warthog.procyon.org.uk> To: Linus Torvalds Cc: dhowells@redhat.com, Matthew Wilcox , Steve French , Vishal Moola , Andrew Morton , Jan Kara , Paulo Alcantara , Huang Ying , Baolin Wang , Xin Hao , linux-mm@kvack.org, mm-commits@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH] cifs: Fix cifs_writepages_region() MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2392015.1677272298.1@warthog.procyon.org.uk> Date: Fri, 24 Feb 2023 20:58:18 +0000 Message-ID: <2392016.1677272298@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Rspamd-Queue-Id: 0167B40004 X-Stat-Signature: iotxshfy3x1z5dqejoxd6amxc5e4p7m3 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1677272305-143996 X-HE-Meta: U2FsdGVkX18eaPV3lzA1dx5bZZjqHuQXNn+igdkzyW1X9EvY+pRpYEKHF6bHITtHp35I4tdwjKZt/zjCWqM6l5eo0W75gAGeSxxVdmjVjhI7/g1EgBs2wS+Y/Z19/SI+85zNGrVi8ZkaYPJTbG1ik8RFw5RcRDAaIkhUI2H7i+VZ43PzurSKJxc4OU9g5srZB6NGr8lYBVTPSAkPo4oPfnbHBKctve2OHLHwpuSCXcNJ/B+CC4MtOceUaKnPC9+vA23vfwW2HCukbDTO+dqKa+OZhxSQkNnPrhqVDmXzAA9ZRRZojgc7pLrPlf4LkDUDWY8dCtwaetxxhhc7P7BZht5+09e6w4VnNANn+S8e5S4FkI429ZptrpeS2UL1vv95gy36aiLR3/mxTms6k0mhDS7gW7X5eGpLsxLMz4gMmr1LwjhuPugbDNZtiKccUgsq9sgNd2uCNZNMAAUMV8+atC0ttNr/9IDbyDli+oFq9ulegoJ3J/NrBxl+ZlWvnmyQIei6ndDD3/1IlniWdjnpn+ePbQrVFvbVObvXlQBZnLii8KjnWwfpt/AOkKaEGh2lEyAL+ftjce4PCseWHQbKpW8bP9/XqpmuByJ5h4KpaVhoawYd/l4mdecBXubShdXwfK0Tuh/lOlvJATd5FOGkRqEROODlTMMdgLBktSg91Ku0tXDJGBsvO+sqe5ix4P5ufTk4MRX8cYfVEQwU4SSntuKra/2a+VVENXxpriAMtO7f61RFW5ucOrgYKW4bdVjTRGlYexH9/65nt8o6ExYes8LJai+j1MhMLv5STxDZWxdhClFZzAgWNIz0/l7b5ns3T4JfCQlzbRBPPQCcDi7xBkwY2uPMB94PLuaB2OEPdnSvcC4po+g7FE7df3aCIK6PDpT8VHUUl44/Qg+gWdA8dmOJQVl5+SnzvU6UmREseD0ctSSDU72oEBiVl29cgljm8cRpUQz+ZoH+kvkFvHg OTgMJOQk dNfQfcqq7akkwLHzWUSuYG/D3Dit/Hm/kOXRt1RG3QdCq5oMBfGR2VvpVVEDjwE0y7u4P69oD7dZCcxlz31jAxIAB8mY9NePAeJqMp3DiC0qkvk2WhHtHCud0iEcLQpHeddaBsphehSOR2ucD0l3Ud0wOjRxGmpoqhyVP2dcO2y3GEnp4H/iM0SCyYpVuho7t2dl+n3WnlcB9UjTPt5M4w7vwnd4amSOhQFFCtIZHRvL4gjZiSgDSfXWphO+Ey2Xwup8HU8DIdcFJaIpPsjphdLiOaIUoj7IAPkg77rwt8n03seasa51l4CTJbuQJA9ts5ydwl4fadi0dN85InhqtfIPrFS3VoyrCW4oU 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: Linus Torvalds wrote: > > Then why do we have to wait for PG_writeback to complete? > > At least for PG_writeback, it's about "the _previous_ dirty write is > still under way, but - since PG_dirty is set again - the page has been > dirtied since". > > So we have to start _another_ writeback, because while the current > writeback *might* have written the updated data, that is not at all > certain or clear. As I understand it, it's also about serialising writes from the same page to the same backing store. We don't want them to end up out-of-order. I'm not sure what guarantees, for instance, the block layer gives if two I/O requests go to the same place. > I'm not sure what the fscache rules are. I'm now using PG_fscache in exactly the same way: the previous write to the cache is still under way. I don't want to start another DIO write to the cache for the same pages. Hence the waits/checks on PG_fscache I've added anywhere we need to wait/check on PG_writeback. As I mentioned I'm looking at the possibility of making PG_dirty and PG_writeback cover *both* cases and recording the difference elsewhere - thereby returning PG_private_2 to the VM folks who'd like their bit back. This means, for instance, when we read from the server and find we need to write it to the cache, we set a note in the aforementioned elsewhere, mark the page dirty and leave it to writepages() to effect the write to the cache. It could get tricky because we have two different places to write to, with very different characteristics (e.g. ~6000km away server vs local SSD) with their own queueing, scheduling, bandwidth, etc. - and the local disk might have to share with the system. David