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 42929C7EE2D for ; Fri, 24 Feb 2023 17:15:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 53CBF6B0071; Fri, 24 Feb 2023 12:15:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4EC926B0073; Fri, 24 Feb 2023 12:15:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B55D6B0074; Fri, 24 Feb 2023 12:15:53 -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 286856B0071 for ; Fri, 24 Feb 2023 12:15:53 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id DEF7F1A08CE for ; Fri, 24 Feb 2023 17:15:52 +0000 (UTC) X-FDA: 80502837744.22.B959C54 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf25.hostedemail.com (Postfix) with ESMTP id 7C4D0A0030 for ; Fri, 24 Feb 2023 17:15:50 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="Ml/t+egV"; spf=pass (imf25.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=1677258951; 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=WPkHpOzfb+zV5/yZOjrh62ZdI6JAwYRbAGW5gOkT0xI=; b=EPRMeUGEiopQEdyX07iGM6OYYzRHeYd8aoaBG4Ih4vIfSrd1clzrCBtWvdDGgNNfBUgsuc fhPfHMz+bv/N3xBSmYnM2zvZz4mP7+l/BCwdoAJefWJQrBgzoZR8mHsGpxF2oa7hiduftr eGbfeKDIrySAbAVy5UfZd+hzF00iYjY= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="Ml/t+egV"; spf=pass (imf25.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=1677258951; a=rsa-sha256; cv=none; b=2aeqvekiWnFkU07Bvh962GebJimMMrpKMeznC8j1lGhRQBExfbabg1wCODSaLynneoUkz7 y+9THuQpYRctbHmZbl0ItjqLZR55EL7hM2/tSCrgOgnbDz/ZrpbHF5C2E2cnPxzeHZ+zDh W7BYZmNbAFp8GiTIJTI3T59LrTQr9/I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677258949; 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=WPkHpOzfb+zV5/yZOjrh62ZdI6JAwYRbAGW5gOkT0xI=; b=Ml/t+egV9/0BkQH6xbguOwzZTTRuFNgwkBn0yCkWt28t3xXQDT/pSRyYsNGOLzqQBeXwS6 t/enJMLGAleh9GLpHFipQ7R6O0+IefX1Ai7A9vPTAQV7q/R8Earixwtk1X8X6CA6LzNN3n EVIQJQOZDyDDH1a8Mb6CA5tLUhQ5Nq0= 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-593-34zRzHVjP5yrZiL2i7p_yA-1; Fri, 24 Feb 2023 12:15:45 -0500 X-MC-Unique: 34zRzHVjP5yrZiL2i7p_yA-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 66CA18432D0; Fri, 24 Feb 2023 17:15:44 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.33.36.18]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7DCEC492B07; Fri, 24 Feb 2023 17:15:42 +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> 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: <2385088.1677258941.1@warthog.procyon.org.uk> Date: Fri, 24 Feb 2023 17:15:41 +0000 Message-ID: <2385089.1677258941@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Stat-Signature: 5io5ur4pmzp9uour9ferjk33diejmdsa X-Rspam-User: X-Rspamd-Queue-Id: 7C4D0A0030 X-Rspamd-Server: rspam06 X-HE-Tag: 1677258950-991768 X-HE-Meta: U2FsdGVkX18mqY4qhZ7Fhozt+JAybMfw5luffHmPGfaWRg6OSJ37KniIJNiqekJ+Wwfp0Gfx1qqI4F3rPd/HAZY+czdR5yj+9TnXO2aCmc+kDQ4mQxBtprVZgQhGTBtBC7/onfUHtOUkUeVDfghyM4GQUXfKjUVEyw5nfAhn8whSZh44ELZc286dOC7Eh5+RZoAAv71q/HPZP8MTh90HH0aFmUjS0xEWs77jUs5o3CsWhJkngmex7cQ4o7C3UNEPDSOK/ewvAARtPI0W924puc+wgvGCmWg/KYJSg7VB0pSoYPnQWiiPdFGpqb4mvhG/pH7P17GrFf4ZKbmEWzfQlAYSVXtGSYv+GjiuZnDbytqzCezuXKERdRFqcxao3+nSeQcahIF6WvJ7KB9Jh1Uf7jDaj9RzznxuaAt0SIEabfrAoMjNg/FY494148hNErNYjU7ruXMjBQsO4eF7AeRf9Sfoo/wg/RQuzoLXM5yPC+R4VXXhvqPGQOwMYmsx/y7uoit7j8/Lpq+BXJGwhPL54xXk4OJzkeInMpsVsMr4OCwy/P6fe2kD8aN/8ZF2ji5G+Hvc9fg1i3oTylg4Vec4bHx9Qz6KHkJGlOmDJTJTtvz2FsDVk84LxJphggNs/usCgx4Q2HE+XlQgSjKx/Sy27Q2VUdn7oLhtsXKsoyrpQ7Jy0E7RT0csxtXb8GCJbhh+qzWd8BMLpq9FvYJo2gIF2DaI1c5YBRQG3n92h5f9upCpi0DvHfBOi1yKEJz0PO9WMTW0/lxtewseYzdxR3XMV9rGYsuRrgm0v3rVjQ7EOYwqta+uhLt08975XrO/T564KDup4/kc7UpII+WPwPA+qZcEiC30E0oH+BKY2Z3R4holVif05Yq6oKcMUKlvrkCYD0i5adkMYv9GOnbx0mdd32Y1dK8izgoC9iVkOlsLu+XXPt9IX3ZwCrQOlzr4Q8YEIsmj9d5S7XWmw8gm5sB v09LEgZn iJjD3UUZh3xFNqRwrkhE+vVSsed6yKTZU91A8CYvnHkKGEO4+0L62wmhvm1o53sR5B9K/jn7Btxv4oPe5/eOHPYgcQq3hjH0aULcsLYDRbSBTxLZr3P1IPEudIWPaiI0PNUczginJMaGIVPkqNLg+/2u3j+v1H0zj4JGtvBpvpk9kVj8Zy3wze78fXuEUSTUnQNszoX9qLP+HCB8q185hCIxQWIvdXA/BTA+35emaftMlNgNj30ExxCumo3Y2XNoP71jWS2qxa2VujDwlM6edmcohxEqTyb6zqOsv2//bnIEI6elpGRhfNBe9eK27KDQpt4TT46TogCXYxFHTkkfjbALc3RAk2CiqKNg8 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: > Why are you doing it this way? What's wrong with using > write_cache_pages() to push all the contiguous dirty folios into a single > I/O object, submitting it when the folios turn out not to be contiguous, > or when we run out of a batch? > > You've written an awful lot of code here and it's a different model from > every other filesystem. Why is it better? Because write_cache_pages(): (1) Takes no account of fscache. I can't just build knowledge of PG_fscache into it because PG_private_2 may be used differently by other filesystems (btrfs, for example). (I'm also trying to phase out the use of PG_private_2 and instead uses PG_writeback to cover both and the difference will be recorded elsewhere - but that's not there yet). (2) Calls ->writepage() individually for each folio - which is excessive. In AFS's implementation, we locate the first folio, then race through the following folios without ever waiting until we hit something that's locked or a gap and then stop and submit. write_cache_pages(), otoh, calls us with the next folio already undirtied and set for writeback when we find out that we don't want it yet. (3) Skips over holes, but at some point in the future we're going to need to schedule adjacent clean pages (before and after) for writeback too to handle transport compression and fscache updates if the granule size for either is larger than the folio size. It might be better to take what's in cifs, generalise it and replace write_cache_pages() with it, then have a "->submit_write()" aop that takes an ITER_XARRAY iterator to write from. David