From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753642AbbGOWOm (ORCPT ); Wed, 15 Jul 2015 18:14:42 -0400 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:5157 "EHLO mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752007AbbGOWOl (ORCPT ); Wed, 15 Jul 2015 18:14:41 -0400 Message-ID: <55A6DB30.50300@fb.com> Date: Wed, 15 Jul 2015 16:14:08 -0600 From: Jens Axboe User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mike Snitzer CC: Austin S Hemmelgarn , , Subject: Re: [PATCH 3/3] block: by default, limit maximum discard size to 64MB References: <1436899703-31966-1-git-send-email-axboe@fb.com> <1436899703-31966-4-git-send-email-axboe@fb.com> <20150714204419.GA7915@redhat.com> <55A57507.1030302@fb.com> <55A5839F.8060608@fb.com> <55A64828.6030007@gmail.com> <55A67C9D.7000009@fb.com> <20150715162959.GA14196@redhat.com> In-Reply-To: <20150715162959.GA14196@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.52.123] X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-07-15_07:2015-07-15,2015-07-15,1970-01-01 signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/15/2015 10:29 AM, Mike Snitzer wrote: > On Wed, Jul 15 2015 at 11:30am -0400, > Jens Axboe 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 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 >>>>>> >>>>>> 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 ;) Lets focus on patch 1+2 for now, so I can queue those up. Acked/reviewed-by's welcome. Then we can tackle the "what is a sane default and for whom" patch 3 later, it's orthogonal to exposing the knob. -- Jens Axboe