[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200915070522.GA19974@lst.de>
Date: Tue, 15 Sep 2020 09:05:22 +0200
From: Christoph Hellwig <hch@....de>
To: Mike Snitzer <snitzer@...hat.com>
Cc: Christoph Hellwig <hch@....de>, Jens Axboe <axboe@...nel.dk>,
linux-block@...r.kernel.org, martin.petersen@...cle.com,
Hans de Goede <hdegoede@...hat.com>,
Song Liu <song@...nel.org>,
Richard Weinberger <richard@....at>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-raid@...r.kernel.org, Minchan Kim <minchan@...nel.org>,
dm-devel@...hat.com, linux-mtd@...ts.infradead.org,
linux-mm@...ck.org, drbd-dev@...n.linbit.com,
cgroups@...r.kernel.org
Subject: Re: [PATCH 06/14] block: lift setting the readahead size into the
block layer
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 underlying devices on a live DM device (done using
> __bind).
>
> Both dm_setup_md_queue() and __bind() call dm_table_set_restrictions()
> to set/update queue_limits. It feels like __bind() will need to call a
> new block helper to set/update parts of queue_limits (e.g. ra_pages and
> io_pages).
>
> Any chance you're open to factoring out that block function as an
> exported symbol for use by blk_register_queue() and code like DM's
> __bind()?
I agree with the problem statement. OTOH adding an exported helper
for two trivial assignments seems a little silly..
For now I'll just keep the open coded ->io_pages assignment in
dm. Note that dm doesn't currently update the ->ra_pages value
based on the underlying devices, so an incremental patch to do that
might be useful as well.
Powered by blists - more mailing lists