[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <877902.1712591597@warthog.procyon.org.uk>
Date: Mon, 08 Apr 2024 16:53:17 +0100
From: David Howells <dhowells@...hat.com>
To: Christian Brauner <christian@...uner.io>,
Matthew Wilcox <willy@...radead.org>
Cc: dhowells@...hat.com, Jeff Layton <jlayton@...nel.org>,
Gao Xiang <hsiangkao@...ux.alibaba.com>,
Dominique Martinet <asmadeus@...ewreck.org>,
Steve French <smfrench@...il.com>,
Marc Dionne <marc.dionne@...istor.com>,
Paulo Alcantara <pc@...guebit.com>,
Shyam Prasad N <sprasad@...rosoft.com>, Tom Talpey <tom@...pey.com>,
Eric Van Hensbergen <ericvh@...nel.org>,
Ilya Dryomov <idryomov@...il.com>, netfs@...ts.linux.dev,
linux-cachefs@...hat.com, linux-afs@...ts.infradead.org,
linux-cifs@...r.kernel.org, linux-nfs@...r.kernel.org,
ceph-devel@...r.kernel.org, v9fs@...ts.linux.dev,
linux-erofs@...ts.ozlabs.org, linux-fsdevel@...r.kernel.org,
linux-mm@...ck.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, Latchesar Ionkov <lucho@...kov.net>,
Christian Schoenebeck <linux_oss@...debyte.com>
Subject: Re: [PATCH 23/26] netfs: Cut over to using new writeback code
David Howells <dhowells@...hat.com> wrote:
> + /* Wait for writeback to complete. The writeback engine owns
> + * the info in folio->private and may change it until it
> + * removes the WB mark.
> + */
> + if (folio_wait_writeback_killable(folio)) {
> + ret = written ? -EINTR : -ERESTARTSYS;
> + goto error_folio_unlock;
> + }
> +
It turns out that this really kills performance with fio with as many jobs as
cpus. It's taking up to around 8x longer to complete a pwrite() on average
and perf shows a 30% of the CPU cycles are being spent in contention on the
i_rwsem.
The reason this was added here is that writeback cannot take the folio lock in
order to clean up folio->private without risking deadlock vs the truncation
routines (IIRC).
I can mitigate this by skipping the wait if folio->private is not set and if
we're not going to attach anything there (see attached). Note that if
writeout is ongoing and there is nothing attached to ->private, then we should
not be engaging write-streaming mode and attaching a new netfs_folio (and if
we did, we'd flush the page and wait for it anyway).
The other possibility is if we have a writeback group to set. This only
applies to ceph for the moment and is something that will need dealing with
if/when ceph is made to use this code.
David
---
diff --git a/fs/netfs/buffered_write.c b/fs/netfs/buffered_write.c
index 1eff9413eb1b..279b296f8014 100644
--- a/fs/netfs/buffered_write.c
+++ b/fs/netfs/buffered_write.c
@@ -255,7 +255,8 @@ ssize_t netfs_perform_write(struct kiocb *iocb, struct iov_iter *iter,
* the info in folio->private and may change it until it
* removes the WB mark.
*/
- if (folio_wait_writeback_killable(folio)) {
+ if (folio_get_private(folio) &&
+ folio_wait_writeback_killable(folio)) {
ret = written ? -EINTR : -ERESTARTSYS;
goto error_folio_unlock;
}
Powered by blists - more mailing lists