Re: [RFC PATCH 1/1] block/ioctl: Add an ioctl to enable large folios for block buffered IO path

[Bharata B Rao <bharata@amd.com>]

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@kernel.org/

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.