Message ID | 2244151.1677251586@warthog.procyon.org.uk |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp971749wrd; Fri, 24 Feb 2023 07:24:04 -0800 (PST) X-Google-Smtp-Source: AK7set93XpR9Zr80hmFb87Fn6pI16As7zvQgMwMGIqj9leBXuEVhA7nsVh66ngFx0UEvciA3ikX2 X-Received: by 2002:a05:6a20:3d1f:b0:b8:c6ec:a269 with SMTP id y31-20020a056a203d1f00b000b8c6eca269mr20048510pzi.16.1677252243986; Fri, 24 Feb 2023 07:24:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1677252243; cv=none; d=google.com; s=arc-20160816; b=m80imDu4cr4SsGu5QGY1NuHh/5agZ4daWQOSGywCb7LZmAsRY6l30ni1MUE3XroAkx Wlt8w1pe67VDg+HaFovIDjyUOnFv/6LpqsfKG+7iyR07VUNRec1SXbJeb02nn3Kvp8gv GXRTXp6sOB19iC7V/jpo9T4JfVlx17II6qkWc5CVY0W/2lyuWqdMhWcmwzz6fsSCMp+v Mnt8FHlHbdw+ZX8Xs9K5DWtqI2c/br70VsNNnpi/fTTM1JGZWAlDdG/fN4V6eehrHulc 3uM2CYANN9SWGDWSHyZbmC8FgsTf8lXq0Bhf+BbLfucVOxk9zshRY4RAI0PMrsEH6ZY7 PK0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:content-transfer-encoding :content-id:mime-version:subject:cc:to:references:in-reply-to:from :organization:dkim-signature; bh=GQh9PzREi1aKG+cvDq/BudsqXqu0IrqPEQVrEk5VEng=; b=iTAo35nhxNfR062fkFVv+H0B6WjwWi+TeL98qogJdUkaBqB20GZ+9a0t/MKf64hMWS U7/Bf3LA6CcW+9xB/MHGXv3BvdrM8AI6L6A8cMBp0+1KK1fh+5ixYmKyqfzYnOINMBe8 i3If92GCX7QI2MU1Q8w6rLkNuoNJisqt54Y9XRquf9bJfhiPoYoHeIsRBb1r9HbYlTaI HPj+WL/0Gpysj7TANIxQdkoAJnrpyePO3HcHCDpxGn8mRmF6T2HvkWt7Vae/kUH1SojN UDgk45IOImbc5r4ZO0h3hmEmd+dPnsp2ySw16NC6e6yBseDPBzOp+pqs7FZZ1kfbD3r5 EJVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=DMUYxNW2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a24-20020a656558000000b004fbb85cb131si9543717pgw.11.2023.02.24.07.23.46; Fri, 24 Feb 2023 07:24:03 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=DMUYxNW2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229988AbjBXPU0 (ORCPT <rfc822;jeff.pang.chn@gmail.com> + 99 others); Fri, 24 Feb 2023 10:20:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43692 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229689AbjBXPUZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 24 Feb 2023 10:20:25 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E6BC855047 for <linux-kernel@vger.kernel.org>; Fri, 24 Feb 2023 07:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677251958; 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=GQh9PzREi1aKG+cvDq/BudsqXqu0IrqPEQVrEk5VEng=; b=DMUYxNW2CKnZL6CtqvRXXT/I56on4JlzFtgCy8jSJy0C5PRceB9EP0uoZTN7oU2DXCJ+4Q 3TC5GpZqZmKSTGWKp0lyzLacCUUrnLaGI59G7kSv0SzDsFEygB60Q+ZlxX6Pk1Sl7pTQ5c +QR0VI2VPnV7Um2E2ytqpI6/PplwWBU= 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-656-ZGuU11x2PtyBMDfxKc7VNQ-1; Fri, 24 Feb 2023 10:13:09 -0500 X-MC-Unique: ZGuU11x2PtyBMDfxKc7VNQ-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9C9F6800B23; Fri, 24 Feb 2023 15:13:08 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.33.36.18]) by smtp.corp.redhat.com (Postfix) with ESMTP id CBAC7492B12; Fri, 24 Feb 2023 15:13:06 +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 <dhowells@redhat.com> In-Reply-To: <2213409.1677249075@warthog.procyon.org.uk> References: <2213409.1677249075@warthog.procyon.org.uk> <2134430.1677240738@warthog.procyon.org.uk> <2009825.1677229488@warthog.procyon.org.uk> <CAHk-=whAAOVBrzwb2uMjCmdRrtudGesYj0tuqdUgi8X_gbw1jw@mail.gmail.com> <20230220135225.91b0f28344c01d5306c31230@linux-foundation.org> To: Linus Torvalds <torvalds@linux-foundation.org>, Steve French <stfrench@microsoft.com> Cc: dhowells@redhat.com, Vishal Moola <vishal.moola@gmail.com>, Andrew Morton <akpm@linux-foundation.org>, Jan Kara <jack@suse.cz>, Paulo Alcantara <pc@cjr.nz>, Matthew Wilcox <willy@infradead.org>, Huang Ying <ying.huang@intel.com>, Baolin Wang <baolin.wang@linux.alibaba.com>, Xin Hao <xhao@linux.alibaba.com>, linux-mm@kvack.org, mm-commits@vger.kernel.org, linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [RFC][PATCH] cifs: Improve use of filemap_get_folios_tag() MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2244150.1677251586.1@warthog.procyon.org.uk> Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Feb 2023 15:13:06 +0000 Message-ID: <2244151.1677251586@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1758726448921118004?= X-GMAIL-MSGID: =?utf-8?q?1758726448921118004?= |
Series |
[RFC] cifs: Improve use of filemap_get_folios_tag()
|
|
Commit Message
David Howells
Feb. 24, 2023, 3:13 p.m. UTC
[This additional to the "cifs: Fix cifs_writepages_region()" patch that I
posted]
The inefficiency derived from filemap_get_folios_tag() get a batch of
contiguous folios in Vishal's change to afs that got copied into cifs can
be reduced by skipping over those folios that have been passed by the start
position rather than going through the process of locking, checking and
trying to write them.
A similar change would need to be made in afs, in addition to fixing the bugs
there.
There's also a fix in cifs_write_back_from_locked_folio() where it doesn't
return the amount of data dispatched to the server as ->async_writev() just
returns 0 on success.
Signed-off-by: David Howells <dhowells@redhat.com>
---
Comments
On Fri, Feb 24, 2023 at 7:13 AM David Howells <dhowells@redhat.com> wrote: > > The inefficiency derived from filemap_get_folios_tag() get a batch of > contiguous folios in Vishal's change to afs that got copied into cifs can > be reduced by skipping over those folios that have been passed by the start > position rather than going through the process of locking, checking and > trying to write them. This patch just makes me go "Ugh". There's something wrong with this code for it to need these games. That just makes me convinced that your other patch that just gets rid of the batching entirely is the right one. Of course, I'd be even happier if Willy is right and the code could use the generic write_cache_pages() and avoid all of these things entirely. I'm not clear on why cifs and afs are being so different in the first place, and some of the differences are just odd (like that skip count). Linus
Linus Torvalds <torvalds@linux-foundation.org> wrote: > Of course, I'd be even happier if Willy is right and the code could > use the generic write_cache_pages() and avoid all of these things > entirely. I'm not clear on why cifs and afs are being so different in > the first place, and some of the differences are just odd (like that > skip count). The main reason is that write_cache_pages() doesn't (and can't) check PG_fscache (btrfs uses PG_private_2 for other purposes). NFS, 9p and ceph, for the moment, don't cache files that are open for writing, but I'm intending to change that at some point. The intention is to unify the writepages code for at least 9p, afs, ceph and cifs in netfslib in the future. David
diff --git a/fs/cifs/file.c b/fs/cifs/file.c index ebfcaae8c437..bae1a9709e32 100644 --- a/fs/cifs/file.c +++ b/fs/cifs/file.c @@ -2839,6 +2839,7 @@ static ssize_t cifs_write_back_from_locked_folio(struct address_space *mapping, free_xid(xid); if (rc == 0) { wbc->nr_to_write = count; + rc = len; } else if (is_retryable_error(rc)) { cifs_pages_write_redirty(inode, start, len); } else { @@ -2873,6 +2874,13 @@ static int cifs_writepages_region(struct address_space *mapping, for (int i = 0; i < nr; i++) { ssize_t ret; struct folio *folio = fbatch.folios[i]; + unsigned long long fstart; + + fstart = folio_pos(folio); /* May go backwards with THPs */ + if (fstart < start && + folio_size(folio) <= start - fstart) + continue; + start = fstart; redo_folio: start = folio_pos(folio); /* May regress with THPs */