public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/2] xfs: streamline xfs_getfsmap performance
Date: Fri, 2 Oct 2020 10:58:08 -0700	[thread overview]
Message-ID: <20201002175808.GZ49547@magnolia> (raw)
In-Reply-To: <20201002071505.GB32516@infradead.org>

On Fri, Oct 02, 2020 at 08:15:05AM +0100, Christoph Hellwig wrote:
> On Thu, Oct 01, 2020 at 09:49:30PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> > 
> > Refactor xfs_getfsmap to improve its performance: instead of indirectly
> > calling a function that copies one record to userspace at a time, create
> > a shadow buffer in the kernel and copy the whole array once at the end.
> > This should speed it up significantly.
> 
> So we save an indirect call and uaccess_enable/disable per entry,
> but pay for it with the cost of a memory allocation (and actually
> using that memory).
> 
> Doesn't seem like an obvious win to me, do you have numbers?

On my 2TB /home partition, the runtime to retrieve 6.4 million fsmap
records drops from 107s to 85s.

It also occurs to me that the current code also copies to userspace
while holding the AGF buffer lock (or the rt bitmap ilock) which we
shouldn't be doing because the userspace buffer could very well be a
mmap file on the same volume, in which case a page_mkwrite could cause
allocation activity.

Hmm, maybe I should tamp down the allocation behavior too, since we
could just do 64k or pagesize or whatever; userspace can call us back
since we set it up for easy iteration.

--D

  reply	other threads:[~2020-10-02 17:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-02  4:49 [PATCH 0/2] xfs: a few fixes and cleanups to GETFSMAP Darrick J. Wong
2020-10-02  4:49 ` [PATCH 1/2] xfs: limit entries returned when counting fsmap records Darrick J. Wong
2020-10-02  7:06   ` Christoph Hellwig
2020-10-02  8:51   ` Chandan Babu R
2020-10-02  4:49 ` [PATCH 2/2] xfs: streamline xfs_getfsmap performance Darrick J. Wong
2020-10-02  7:15   ` Christoph Hellwig
2020-10-02 17:58     ` Darrick J. Wong [this message]
2020-10-05  6:30       ` Christoph Hellwig
2020-10-05 17:02         ` Darrick J. Wong
2020-10-02  8:52   ` Chandan Babu R
2020-10-04 19:14   ` [PATCH v1.2 2/2] xfs: fix deadlock and " Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201002175808.GZ49547@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=hch@infradead.org \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox