Re: [PATCH 2/2] xfs: streamline xfs_getfsmap performance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
> > 
> > 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



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux