Re: [PATCH 1/7] xfs: increase the default parallelism levels of pwork clients

Darrick J. Wong
2021-01-14T21:34:01Z

On Wed, Jan 13, 2021 at 03:49:32PM +0100, Christoph Hellwig wrote:
> > +/* Estimate the amount of parallelism available for a given device. */
> > +unsigned int
> > +xfs_buftarg_guess_threads(
> > + struct xfs_buftarg *btp)
> > +{
> > + int iomin;
> > + int ioopt;
> > +
> > + /*
> > + * The device tells us that it is non-rotational, and we take that to
> > + * mean there are no moving parts and that the device can handle all
> > + * the CPUs throwing IO requests at it.
> > + */
> > + if (blk_queue_nonrot(btp->bt_bdev->bd_disk->queue))
> > + return num_online_cpus();
> > +
> > + /*
> > + * The device has a preferred and minimum IO size that suggest a RAID
> > + * setup, so infer the number of disks and assume that the parallelism
> > + * is equal to the disk count.
> > + */
> > + iomin = bdev_io_min(btp->bt_bdev);
> > + ioopt = bdev_io_opt(btp->bt_bdev);
> > + if (iomin > 0 && ioopt > iomin)
> > + return ioopt / iomin;
> > +
> > + /*
> > + * The device did not indicate that it has any capabilities beyond that
> > + * of a rotating disk with a single drive head, so we estimate no
> > + * parallelism at all.
> > + */
> > + return 1;
> > +}
>
> Why is this in xfs_buf.c despite having nothing to do with the buffer
> cache?

Initially I assigned it to the buftarg code on the grounds that this is
how you'd estimate the level of parallelism available through the data
device buftarg.

I don't really care where it goes, though. xfs_pwork_guess_threads
would be fine too.

> Also I think we need some sort of manual override in case the guess is
> wrong.

Hm, where would we put it? One of the xfs sysctls? And would we be
able to resize the background blockgc workqueue size too?

--D