Jens Axboe <ax...@fb.com> writes: > Lots of devices support huge discard sizes these days. Depending > on how the device handles them internally, huge discards can > introduce massive latencies (hundreds of msec) on the device side. > > We have a sysfs file, discard_max_bytes, that advertises the max > hardware supported discard size. Make this writeable, and split > the settings into a soft and hard limit. This can be set from > 'discard_granularity' and up to the hardware limit. > > Add a new sysfs file, 'discard_max_hw_bytes', that shows the hw > set limit. > > Signed-off-by: Jens Axboe <ax...@fb.com> > --- > Documentation/block/queue-sysfs.txt | 4 +++- > block/blk-settings.c | 4 ++++ > block/blk-sysfs.c | 40 > ++++++++++++++++++++++++++++++++++++- > include/linux/blkdev.h | 1 + > 4 files changed, 47 insertions(+), 2 deletions(-) > > diff --git a/Documentation/block/queue-sysfs.txt > b/Documentation/block/queue-sysfs.txt > index 3a29f8914df9..3748cf827131 100644 > --- a/Documentation/block/queue-sysfs.txt > +++ b/Documentation/block/queue-sysfs.txt > @@ -20,7 +20,7 @@ This shows the size of internal allocation of the device in > bytes, if > reported by the device. A value of '0' means device does not support > the discard functionality. > > -discard_max_bytes (RO) > +discard_max_bytes (RW) > ---------------------- > Devices that support discard functionality may have internal limits on > the number of bytes that can be trimmed or unmapped in a single operation. > @@ -28,6 +28,8 @@ The discard_max_bytes parameter is set by the device driver > to the maximum > number of bytes that can be discarded in a single operation. Discard > requests issued to the device must not exceed this limit. A discard_max_bytes > value of 0 means that the device does not support discard functionality. > +Writing a lower value to this file can limit the maximum discard size issued > +to the device, which can help latencies.
You forgot to add a new entry for discard_max_hw_bytes. Fix that and you can slap my 'Reviewed-by: Jeff Moyer <jmo...@redhat.com>' on there. Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
