On 27-Nov-24 11:56 AM, Christoph Hellwig wrote:
On Wed, Nov 27, 2024 at 11:17:37AM +0530, Bharata B Rao wrote:
In order to experiment using large folios for block devices read/write
operations, expose an ioctl that userspace can selectively use on the
raw block devices.
For the write path, this forces iomap layer to provision large
folios (via iomap_file_buffered_write()).
Well, unless CONFIG_BUFFER_HEAD is disabled, the block device uses
the buffer head based write path, which currently doesn't fully
support large folios (although there is series out to do so on
fsdevel right now), so I don't think this will fully work.
I believe you are referring to the patchset that enables bs > ps for
block devices -
https://lore.kernel.org/linux-fsdevel/20241113094727.1497722-1-mcgrof@xxxxxxxxxx/
With the above patchset, block device can use buffer head based write
path without disabling CONFIG_BUFFER_HEAD and that is a pre-requisite
for buffered IO path in the block layer (blkdev_buffered_write()) to
correctly/fully use large folios. Did I get that right?
But the more important problem, and the reason why we don't use
the non-buffer_head path by default is that the block device mapping
is reused by a lot of file systems, which are not aware of large
folios, and will get utterly confused. So if we want to do anything
smart on the block device mapping, we'll have to ensure we're back
to state compatible with these file systems before calling into
their mount code, and stick to the old code while file systems are
mounted.
In fact I was trying to see if it is possible to advertise large folio
support in bdev mapping only for those block devices which don't have FS
mounted on them. But apparently it was not so straight forward and my
initial attempt at this resulted in FS corruption. Hence I resorted to
the current ioctl approach as a way to showcase the problem and the
potential benefit.
Of course the real question is: why do you care about buffered
I/O performance on the block device node?
Various combinations of FIO options
(direct/buffered/blocksizes/readwrite ratios etc) was part of a customer
test/regression suite and we found this particular case of FIO with
buffered IO on NVME block devices to have a lot of scalability issues.
Hence checking if there are ways to mitigate those.
Thanks for your reply.
Regards,
Bharata.
