On Thu, Sep 10, 2020 at 01:15:41PM -0400, Mike Snitzer wrote:
> > I'll move it to blk_register_queue, which should work just fine.
>
> That'll work for initial DM table load as part of DM device creation
> (dm_setup_md_queue). But it won't account for DM table reloads that
> might change
On Thu, Sep 10 2020 at 5:28am -0400,
Christoph Hellwig wrote:
> On Wed, Sep 02, 2020 at 12:20:07PM -0400, Mike Snitzer wrote:
> > On Wed, Sep 02 2020 at 11:11am -0400,
> > Christoph Hellwig wrote:
> >
> > > On Wed, Aug 26, 2020 at 06:07:38PM -0400, Mike Snitzer wrote:
> > > > On Sun, Jul 26
On Wed, Sep 02, 2020 at 12:20:07PM -0400, Mike Snitzer wrote:
> On Wed, Sep 02 2020 at 11:11am -0400,
> Christoph Hellwig wrote:
>
> > On Wed, Aug 26, 2020 at 06:07:38PM -0400, Mike Snitzer wrote:
> > > On Sun, Jul 26 2020 at 11:03am -0400,
> > > Christoph Hellwig wrote:
> > >
> > > > Drivers
On Wed, Sep 02 2020 at 11:11am -0400,
Christoph Hellwig wrote:
> On Wed, Aug 26, 2020 at 06:07:38PM -0400, Mike Snitzer wrote:
> > On Sun, Jul 26 2020 at 11:03am -0400,
> > Christoph Hellwig wrote:
> >
> > > Drivers shouldn't really mess with the readahead size, as that is a VM
> > > concept.
On Wed, Aug 26, 2020 at 06:07:38PM -0400, Mike Snitzer wrote:
> On Sun, Jul 26 2020 at 11:03am -0400,
> Christoph Hellwig wrote:
>
> > Drivers shouldn't really mess with the readahead size, as that is a VM
> > concept. Instead set it based on the optimal I/O size by lifting the
> > algorithm
On Sun, Jul 26 2020 at 11:03am -0400,
Christoph Hellwig wrote:
> Drivers shouldn't really mess with the readahead size, as that is a VM
> concept. Instead set it based on the optimal I/O size by lifting the
> algorithm from the md driver when registering the disk. Also set
> bdi->io_pages
Looks good,
Reviewed-by: Johannes Thumshirn
Drivers shouldn't really mess with the readahead size, as that is a VM
concept. Instead set it based on the optimal I/O size by lifting the
algorithm from the md driver when registering the disk. Also set
bdi->io_pages there as well by applying the same scheme based on
max_sectors.
Drivers shouldn't really mess with the readahead size, as that is a VM
concept. Instead set it based on the optimal I/O size by lifting the
algorithm from the md driver when registering the disk. Also set
bdi->io_pages there as well by applying the same scheme based on
max_sectors.
On Wed, Jul 22, 2020 at 07:13:54AM +, Johannes Thumshirn wrote:
> On 22/07/2020 08:27, Christoph Hellwig wrote:
> > + q->backing_dev_info->ra_pages =
> > + max(queue_io_opt(q) * 2 / PAGE_SIZE, VM_READAHEAD_PAGES);
>
> Dumb question, wouldn't a '>> PAGE_SHIFT' be better instead of
On 22/07/2020 08:27, Christoph Hellwig wrote:
> + q->backing_dev_info->ra_pages =
> + max(queue_io_opt(q) * 2 / PAGE_SIZE, VM_READAHEAD_PAGES);
Dumb question, wouldn't a '>> PAGE_SHIFT' be better instead of a potentially
costly division?
Or aren't we caring at all as it's a) not
Drivers shouldn't really mess with the readahead size, as that is a VM
concept. Instead set it based on the optimal I/O size by lifting the
algorithm from the md driver when registering the disk. Also set
bdi->io_pages there as well by applying the same scheme based on
max_sectors.
Drivers shouldn't really mess with the readahead size, as that is a VM
concept. Instead set it based on the optimal I/O size by lifting the
algorithm from the md driver when registering the disk. Also set
bdi->io_pages there as well by applying the same scheme based on
max_sectors.
13 matches
Mail list logo
