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 ED085C7EE23 for ; Mon, 27 Feb 2023 13:20:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 74F7F6B0072; Mon, 27 Feb 2023 08:20:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7009E6B0073; Mon, 27 Feb 2023 08:20:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C8476B0074; Mon, 27 Feb 2023 08:20:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 4D1426B0072 for ; Mon, 27 Feb 2023 08:20:56 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E3FE540A27 for ; Mon, 27 Feb 2023 13:20:55 +0000 (UTC) X-FDA: 80513132070.06.1B89B46 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf27.hostedemail.com (Postfix) with ESMTP id D5A694001C for ; Mon, 27 Feb 2023 13:20:53 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=K20HJxEX; spf=pass (imf27.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=1677504053; a=rsa-sha256; cv=none; b=EbIBROSgTJsXWnYFQgQBWP7TSAwdmS3rUc8qzCYwa6X7m3Q6cZEi7+1ykkbcsmhfDtH4p4 jPz8PKwwKa1Q+qSO2VfCbnhW0P3xI5RwEK65rhS99LiEJ6c79nRtqVJv/15USih4t0jTob rS9uz9dLeXMtFyerVDHkz0WW5zUrelo= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=K20HJxEX; spf=pass (imf27.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=1677504053; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GIUaC7K1TYqWkgQiMBQCJNQiY2ZClHrxPQ2oiydBZJ4=; b=n1SmAgUEzIni7NQM/zKx84iULMyfmgU0MA8feBg79slhOBHdvZN8Ve/9k+g9jq7Xj58S5i YwVddUqi/h/DFx1VeZu1yU6jo00PxOQ7AqFsIObOUA2nsKjSVkeeEq6AAio84XkEkd6O3c Kodl79rTeH2PqL6l+THQMpxz8SPB5mc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677504053; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GIUaC7K1TYqWkgQiMBQCJNQiY2ZClHrxPQ2oiydBZJ4=; b=K20HJxEXXwARkXCIueLo/peUw09ruA4lZC5U1nyxJnBOoVzjKNTtoNFnd4UW7yOj1xwh5L UkvXpUiow5mdnHwUUjyCsadAlv6S20nCQR9QxuxexBH1sc1vzlivu/sN1Leu5E9bxPgAU9 QL0y10e7++5wvOTj/im0wQ18v6kLPn4= 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-371-oxBDmthhPsi5Sf1kEf0HUg-1; Mon, 27 Feb 2023 08:20:50 -0500 X-MC-Unique: oxBDmthhPsi5Sf1kEf0HUg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3D568101B42B; Mon, 27 Feb 2023 13:20:49 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.33.36.18]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9F2F7404BEC5; Mon, 27 Feb 2023 13:20:46 +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: Matthew Wilcox Cc: dhowells@redhat.com, Linus Torvalds , 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: <2675058.1677504045.1@warthog.procyon.org.uk> Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Feb 2023 13:20:46 +0000 Message-ID: <2675059.1677504046@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Rspam-User: X-Rspamd-Queue-Id: D5A694001C X-Rspamd-Server: rspam01 X-Stat-Signature: uc94575pjwkmy1otquhjj5nfiijbdffj X-HE-Tag: 1677504053-636459 X-HE-Meta: U2FsdGVkX19KXNBc/U40oVwaGH19GoJMpdvcKQZbK/USp7RQIwlsmECf91onHC/h82J06ghpoznzmFKZGW231Xt3ZRRfRDeCyXm5PyU+K+8J6bzycWLSqWyKGV6Pqv3Lf1VmfPU7RVp8V6a1TFyT3DjMh8e44EnI2CQh93+vRZlq1gUeinVAns5AyaaPhe66/fZy8dP4VPYXuOde2vkYXdicZps6kmcnCp8XGf/cvQf76AoW3apcKGf3npvQEBBnTKM5sA8FpJPHK+APgpdnAPJ49KR0JzzYBQ9DNrlD0p3Bo6+jYjw9Q69Tc1aeA8yKV8p13Or20dk+VO69KFGsCgXkZK7sGaLyFC78uprOAW7gnh2R2ex2Y02JWxd50K7MaJq6sQCmLVtMqRGNvBc0hS3I3Ggel8nv4YTg8a5KrkHyOWKpZzm303NT+5zqugx4YAUkblYSKXu6ohy8tdanXvbYALfuc/xOfZZ7Xp+xAHjbGRkNnTdcDaw9JWTRLiVLVxeL482bNk5dXv30jW6f3i9Kn8e4nMI6N12laudz5+owpo7M541yoB4WwUOM5TuPaIrz1dvA58BP4tFLx6qKbacXog5r/JQLKn6FLiPmPDyyknzaPuwLzRQsPhSPZDpnGm34lsww31uLa/b0+wl+xeI2iA5HTY9e4m3jNnjiq0Y7N0OnI7RKX/x8+lgsfLjDZ+X3VjTJ97i4eG8OZHCOlvOZJ+W+I7eeTNGuHYD7i4kij199kA8D95/mj/NfAoAAjKdS612OB3qQyXRLCZpFt4R3FgRHq+unboIUV9gIn6UsX7SwcNavb0Sl2szK5Qn9dWK/Amze35BQX8xpgOLF/BMaf5Swg8zG69u0NQWxut6Z/PgYigRWUZ3Bj8mraQfyp+3VYjbV1d2roUx8uv6e1TaTl6T2CMOaa8x86lpPwOcF/WjQfLx0n2DxPwqJwONXGNcjJ5bsipH4AWHe7W+ 5gIDuwAC otFoDOkCviH7dlMWQ/w7WP9wT76p142+6KnatWynx+Id4dtpfhU/cr8O1TCQlNFS7Om/atzVgmp7Ukc3K8x9R7R02ZCO9Z2T9Qx6lJb+4BL+B1cW9IAC+RT9oeUlomvCJj+fYdZhHMoBaB1Bu6sgFngGBF4MzRz19PzDhnFHUfUQcng5EqVQQWMeuoUqS1nBPba49oWKxLsi1jqdwq8z/NovDB6AQU2BVBJ1sf4qrHePfCkfWaKSim/BtZ4OheXEvKIAjWwye82e1LlbkHHOoOawNHFNAF5rgXlUXDtMgQBjoxPz+2GH+BnTfJRckqSoEExMAzTplh/Yqrxte2ekkWPVKnChhqtA70nr/K42SwEdKBBXUSw3+y0tlJA== 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: Matthew Wilcox wrote: > On Fri, Feb 24, 2023 at 12:16:49PM -0800, Linus Torvalds wrote: > > On Fri, Feb 24, 2023 at 12:14 PM David Howells w= rote: > > > > > > 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. > = > also, we only have a writeback bit, not a writeback count. And when > the current writeback completes, it'll clear that bit. We're also > being kind to our backing store and not writing to the same block twice > at the same time. It's not so much being kind to the backing store, I think, as avoiding the possibility that the writes happen out of order. > > I'm not sure what the fscache rules are. > = > My understanding is that the fscache bit is set under several > circumstances, but if the folio is dirty _and_ the fscache bit > is set, it means the folio is currently being written to the cache > device. I don't see a conflict there; we can write to the backing > store and the cache device at the same time. The dirty bit is nothing to do with it. If the fscache bit is set, then t= he page is currently being written to the cache - and we need to wait before starting another write. Sometimes we start a write to the cache from a clean page (e.g. we just re= ad it from the server) and sometimes we start a write to the cache from writepages (e.g. the data is dirty and we're writing it to the server as well). Things will become more 'interesting' should we ever get around to implementing disconnected operation. Then we might end up staging dirty d= ata through the cache. David