From patchwork Mon Apr 30 23:00:14 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jens Axboe X-Patchwork-Id: 10373051 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 653A66032A for ; Mon, 30 Apr 2018 23:00:39 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4319928BF0 for ; Mon, 30 Apr 2018 23:00:39 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8F762285FC; Mon, 30 Apr 2018 23:00:36 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 114D7286AE for ; Mon, 30 Apr 2018 23:00:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753953AbeD3XAU (ORCPT ); Mon, 30 Apr 2018 19:00:20 -0400 Received: from mail-pg0-f65.google.com ([74.125.83.65]:45838 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753257AbeD3XAS (ORCPT ); Mon, 30 Apr 2018 19:00:18 -0400 Received: by mail-pg0-f65.google.com with SMTP id i29-v6so7249955pgn.12 for ; Mon, 30 Apr 2018 16:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=v9FRySpTIsSTvupA2+MVLJVS1pItKic/9bhV8kJ+HpE=; b=ftPrNjaTOAJSkedY+Tx0yU5wY4qVy2MLe/FBhLyxIDgzZoQ/v/xbzcA/XCXUHt2Nji pAAmlYY4Neb4HDi7cb69WRsc9BhXJVySwcdySv33hStbiYq2z7cvRYPHFeNFMBAZCzrR WW7m8V2Nodj+oOtavRI2Za+zLLa08LRprsqIY+9pcnHSx6LyvfU7n09u5O2aGpRbORgD 0bb05GKINSzEXo+AUUgS7poak4rMpHuk/wyURBvWks2AoPczGvEUyiCdZDQPGS3kQh2G gWicVx8yUab/icwLU5d7qG4FkDDGFJ0gyquQnH4FjmxAiMPy2hJv5kamX/bv3W7+cONJ OWew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=v9FRySpTIsSTvupA2+MVLJVS1pItKic/9bhV8kJ+HpE=; b=A2y2V4JUcXk/Iw0MuH0Rn59GbviMBG5IqeS/Flyg++yf3Nd/0u075ypXwFDq/CLWSB /oyo3MEkIwl3016cVZYqo4lD7rR75dNy+h9wh2zbUz/TEbS03MT/ofYaTXmk+7VTCEVE BpFl0Ndycq4mWltegx4FS8/RQZtbyw6GpmaIy2z42qtDxLEjAP6QXBigCbbBsF8nrEm7 f30T8POSWyQ/mtBTqIvVDs9XYcdR2P2HK6kelZTrrsKm13ZxtiYdvJGIdgl83BQ6N6Go CZOmGjrR1WaMOUL8hcyIWM988EhpiCnGYxIgfXJ5roaAdfKV+ow58XfBi5kND7OM/T6C TjFQ== X-Gm-Message-State: ALQs6tAZw980UIMtL8Lypg6FBQiswTIX9s+P5WSA5DTjpyUPqNLo6tNu hnFFXU8fWqf3SC42XiODmYqbpA== X-Google-Smtp-Source: AB8JxZrgYevSJ4FttQ+3sJsTAXutEweL1KroUId8Ci6Pbj15ruBoHeqr+SoUtq73QKhD8BM83nmc6w== X-Received: by 2002:a65:4244:: with SMTP id d4-v6mr11232845pgq.234.1525129217093; Mon, 30 Apr 2018 16:00:17 -0700 (PDT) Received: from [192.168.1.211] (107.191.0.158.static.utbb.net. [107.191.0.158]) by smtp.gmail.com with ESMTPSA id n67sm12821406pfh.188.2018.04.30.16.00.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Apr 2018 16:00:15 -0700 (PDT) Subject: Re: [PATCH 2/2] xfs: add 'discard_sync' mount flag From: Jens Axboe To: Dave Chinner Cc: linux-xfs@vger.kernel.org, linux-block@vger.kernel.org, hch@lst.de References: <1525102372-8430-1-git-send-email-axboe@kernel.dk> <1525102372-8430-3-git-send-email-axboe@kernel.dk> <20180430213120.GD13766@dastard> <20180430222852.GF13766@dastard> <87589bc6-e5f5-6247-485f-2237e0c493ad@kernel.dk> Message-ID: <799de885-34f0-0cae-ae64-bf7bc194965d@kernel.dk> Date: Mon, 30 Apr 2018 17:00:14 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <87589bc6-e5f5-6247-485f-2237e0c493ad@kernel.dk> Content-Language: en-US Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 4/30/18 4:40 PM, Jens Axboe wrote: > On 4/30/18 4:28 PM, Dave Chinner wrote: >> Yes, it does, but so would having the block layer to throttle device >> discard requests in flight to a queue depth of 1. And then we don't >> have to change XFS at all. > > I'm perfectly fine with making that change by default, and much easier > for me since I don't have to patch file systems. Totally untested, but this should do the trick. It ensures we have a QD of 1 (per caller), which should be sufficient. If people tune down the discard size, then you'll be blocking waiting for discards on issue. diff --git a/block/blk-lib.c b/block/blk-lib.c index a676084d4740..0bf9befcc863 100644 --- a/block/blk-lib.c +++ b/block/blk-lib.c @@ -11,16 +11,19 @@ #include "blk.h" static struct bio *next_bio(struct bio *bio, unsigned int nr_pages, - gfp_t gfp) + gfp_t gfp) { - struct bio *new = bio_alloc(gfp, nr_pages); - + /* + * Devices suck at discard, so if we have to break up the bio + * size due to the max discard size setting, wait for the + * previous one to finish first. + */ if (bio) { - bio_chain(bio, new); - submit_bio(bio); + submit_bio_wait(bio); + bio_put(bio); } - return new; + return bio_alloc(gfp, nr_pages); } int __blkdev_issue_discard(struct block_device *bdev, sector_t sector, @@ -63,7 +66,8 @@ int __blkdev_issue_discard(struct block_device *bdev, sector_t sector, sector_t end_sect, tmp; /* Make sure bi_size doesn't overflow */ - req_sects = min_t(sector_t, nr_sects, UINT_MAX >> 9); + req_sects = min_t(sector_t, nr_sects, + q->limits.max_discard_sectors); /** * If splitting a request, and the next starting sector would be