linux-kernel - Re: [PATCH 3/3] block: by default, limit maximum discard size to 64MB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150715162959.GA14196@redhat.com>
Date:	Wed, 15 Jul 2015 12:29:59 -0400
From:	Mike Snitzer <snitzer@...hat.com>
To:	Jens Axboe <axboe@...com>
Cc:	Austin S Hemmelgarn <ahferroin7@...il.com>,
	linux-kernel@...r.kernel.org, hch@....de
Subject: Re: [PATCH 3/3] block: by default, limit maximum discard size to 64MB

On Wed, Jul 15 2015 at 11:30am -0400,
Jens Axboe <axboe@...com> wrote:

> On 07/15/2015 05:46 AM, Austin S Hemmelgarn wrote:
> >On 2015-07-14 17:48, Jens Axboe wrote:
> >>On 07/14/2015 02:45 PM, Jens Axboe wrote:
> >>>On 07/14/2015 02:44 PM, Mike Snitzer wrote:
> >>>>On Tue, Jul 14 2015 at  2:48pm -0400,
> >>>>Jens Axboe <axboe@...com> wrote:
> >>>>
> >>>>>Lots of devices exhibit very high latencies for big discards, hurting
> >>>>>reads and writes. By default, limit the max discard we will build to
> >>>>>64MB. This value has shown good results across a number of devices.
> >>>>>
> >>>>>This will potentially hurt discard throughput, from a provisioning
> >>>>>point of view (when the user does mkfs.xfs, for instance, and mkfs
> >>>>>issues a full device discard). If that becomes an issue, we could
> >>>>>have different behavior for provisioning vs runtime discards.
> >>>>>
> >>>>>Signed-off-by: Jens Axboe <axboe@...com>
> >>>>
> >>>>Christoph suggested you impose this default for the specific
> >>>>drivers/devices that benefit.  I'm not following why imposing a 64MB
> >>>>default is the right thing to do for all devices.
> >>>
> >>>I'd argue that's most of them... But the testing we did was on NVMe. I
> >>>can limit it to NVMe, no big deal.
> >>
> >>Oh, and LSI flash too, so not just NVMe.
> >>
> >While I don't have time to test it, I have a feeling that such a limit
> >would help with many of the consumer SSD's out there.  Secondarily, once
> >this gets in and discard is fixed for BTRFS, I'll have some performance
> >testing to do WRT dm-thinp.
> 
> Right, that was the point of it. After more consideration, a default
> "sane" limit should be applied to any non-stacked device.

Sounds good.

For DM thinp, it can handle really large discards efficiently (without
passing discards down to the underlying data device).  But if/when
discard passdown is enabled it'll obviously split those larger discards
based on this new "sane" limit of the underlying data device.

Which would then potentially usher in the problem of discard latency
being high for DM thinp (if discard passdown is enabled).  But in
practice I doubt that will be much of a concern.  I'll keep both pieces
if I'm wrong ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/