summaryrefslogtreecommitdiffstats
path: root/rust/helpers/helpers.c
diff options
context:
space:
mode:
authorChristoph Hellwig <hch@lst.de>2025-04-24 10:25:21 +0200
committerJens Axboe <axboe@kernel.dk>2025-04-24 07:32:17 -0600
commit7b720c720253e2070459420b2628a7b9ee6733b3 (patch)
tree87a2118c4c801a4cc9dc988864afd190e0e0b55e /rust/helpers/helpers.c
parent1d019736b6f812bebf3ef89d6e887d06e2a822fc (diff)
downloadlinux-7b720c720253e2070459420b2628a7b9ee6733b3.tar.gz
linux-7b720c720253e2070459420b2628a7b9ee6733b3.tar.bz2
linux-7b720c720253e2070459420b2628a7b9ee6733b3.zip
block: never reduce ra_pages in blk_apply_bdi_limits
When the user increased the read-ahead size through sysfs this value currently get lost if the device is reprobe, including on a resume from suspend. As there is no hardware limitation for the read-ahead size there is no real need to reset it or track a separate hardware limitation like for max_sectors. This restores the pre-atomic queue limit behavior in the sd driver as sd did not use blk_queue_io_opt and thus never updated the read ahead size to the value based of the optimal I/O, but changes behavior for all other drivers. As the new behavior seems useful and sd is the driver for which the readahead size tweaks are most useful that seems like a worthwhile trade off. Fixes: 804e498e0496 ("sd: convert to the atomic queue limits API") Reported-by: Holger Hoffstätte <holger@applied-asynchrony.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Holger Hoffstätte <holger@applied-asynchrony.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Link: https://lore.kernel.org/r/20250424082521.1967286-1-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'rust/helpers/helpers.c')
0 files changed, 0 insertions, 0 deletions