Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1183768 > unrolled thread
| Started by | Jens Axboe <axboe@fb.com> |
|---|---|
| First post | 2015-07-14 17:10 +0200 |
| Last post | 2015-07-14 18:10 +0200 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
[PATCH 0/2] Configurable max discard size Jens Axboe <axboe@fb.com> - 2015-07-14 17:10 +0200
Re: [PATCH 0/2] Configurable max discard size Christoph Hellwig <hch@lst.de> - 2015-07-14 18:10 +0200
Re: [PATCH 0/2] Configurable max discard size Jens Axboe <axboe@fb.com> - 2015-07-14 18:10 +0200
| From | Jens Axboe <axboe@fb.com> |
|---|---|
| Date | 2015-07-14 17:10 +0200 |
| Subject | [PATCH 0/2] Configurable max discard size |
| Message-ID | <pMa0h-3Rk-7@gated-at.bofh.it> |
Hi, Most drivers use UINT_MAX (or some variant thereof) for max discard size, since they don't have a real limit for a non-data transferring command. This is fine from a throughput point of view, but for a lot of devices (all?), it truly sucks on latency. We've seen cases of hundreds of msec in latencies for reads/writes when deleting files on an fs with discard enabled. For the problematic devices that we have tested, artificially limiting the size of the discards issued brings it down to a more manageable 1-2ms max latencies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Christoph Hellwig <hch@lst.de> |
|---|---|
| Date | 2015-07-14 18:10 +0200 |
| Message-ID | <pMaWl-5cM-19@gated-at.bofh.it> |
| In reply to | #1183768 |
On Tue, Jul 14, 2015 at 09:02:17AM -0600, Jens Axboe wrote: > Hi, > > Most drivers use UINT_MAX (or some variant thereof) for max discard > size, since they don't have a real limit for a non-data transferring > command. This is fine from a throughput point of view, but for a lot > of devices (all?), it truly sucks on latency. We've seen cases of > hundreds of msec in latencies for reads/writes when deleting files > on an fs with discard enabled. For the problematic devices that we > have tested, artificially limiting the size of the discards issued > brings it down to a more manageable 1-2ms max latencies. This looks reasonable to me. Any chance you could also come up with reasonable start values for the hardware you've done this for so that we can get a good out of the box experience? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Jens Axboe <axboe@fb.com> |
|---|---|
| Date | 2015-07-14 18:10 +0200 |
| Message-ID | <pMaWm-5cM-31@gated-at.bofh.it> |
| In reply to | #1183822 |
On 07/14/2015 10:01 AM, Christoph Hellwig wrote: > On Tue, Jul 14, 2015 at 09:02:17AM -0600, Jens Axboe wrote: >> Hi, >> >> Most drivers use UINT_MAX (or some variant thereof) for max discard >> size, since they don't have a real limit for a non-data transferring >> command. This is fine from a throughput point of view, but for a lot >> of devices (all?), it truly sucks on latency. We've seen cases of >> hundreds of msec in latencies for reads/writes when deleting files >> on an fs with discard enabled. For the problematic devices that we >> have tested, artificially limiting the size of the discards issued >> brings it down to a more manageable 1-2ms max latencies. > > This looks reasonable to me. Any chance you could also come up > with reasonable start values for the hardware you've done this for > so that we can get a good out of the box experience? Based on experimentation with two different vendors, 64MB would be a good default. Question is how best to set that. At least with the current patch, untouched, 'discard_max_bytes' will still show the hw max value. If I default it to 64MB, we'd lose that information until people started bumping it up in size. Maybe that's not such a big deal, however. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web