Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3468971imu; Sun, 11 Nov 2018 15:49:09 -0800 (PST) X-Google-Smtp-Source: AJdET5cw46T754B9O8sFejIm82iRnbxDuz/iMlLGaItoPix7g4pBGFhymNbgQIpIG4fQ1G+Nk2TM X-Received: by 2002:a63:ec13:: with SMTP id j19mr1454635pgh.6.1541980149353; Sun, 11 Nov 2018 15:49:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541980149; cv=none; d=google.com; s=arc-20160816; b=yXCXxAKN2RSC3J3SD1AUahgBcTBhMEAm5bBHsO4gEKkPVGks/0oA13NO+D362kuE7e j8/Y7pPReymQcqiH9XLPn9hroGn07fifvHyY4JJvCu3+tBG1J5E0qfKzzRufU6GFHKy2 YONC0INx0z00LZczc3GhGqImiuASoZuzmAiQe3QnJuH0mKugAMKIkFMj2gGfuD/lpaSz /xY+a+O5MEhJo3H8W9FrH08D4cJSp0Br5BeoJiX3CVpLT1UJhdTCPtNUHfefbs1LAj93 w8X2rfThEBzr7emy3kfJJnw0QS4Ae3eqy8ZoUGKHYfpvj5E7KdpRMcc23Q4qq7dMgo4z Q4cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=7HrJxcCtwvhD52h+vzOJzcDmMBZnkhDjBNg9x+p5+gc=; b=D6OMnOUvL0Wd5JVG4NLagX7W/OVkqkRpe+OHIeAJ4sxM9bnzytcj7jfl2hmVu4rwHO h6hVFGVH+hfjI3ITJcY+VEveytF+54sdqfASAzZsjvnbExXdlQ3io7nJJzfaQj8Kj9DD u5BqVVWtMvtyS5kL3G+X2o6aJ3ipImtVEO+QD53buM+U5iE6rJ4BKMJ8a7D3kuyU9Lxa fp9n13rU6wpzM6y+OOQwtoBVQlE2zmhzWEoORyz9TdJhLRX2GOscu3qGpSf4JUBaF4La 9Zasu6z9d7qlYhFMBG38aPa4xbWiQOnkHZtkpbZnhs6cF9hGWfCM8Z+1tSalAm6pZohm r+Pg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=AALeqw8P; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j20si14903963pgh.224.2018.11.11.15.48.54; Sun, 11 Nov 2018 15:49:09 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=AALeqw8P; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733098AbeKLISn (ORCPT + 99 others); Mon, 12 Nov 2018 03:18:43 -0500 Received: from mail.kernel.org ([198.145.29.99]:38130 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733070AbeKLISm (ORCPT ); Mon, 12 Nov 2018 03:18:42 -0500 Received: from localhost (unknown [206.108.79.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5A07921508; Sun, 11 Nov 2018 22:28:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1541975326; bh=cN0wSZxstLfEOKx1EFausJa3RJkM0U+vew/d2orEHEg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AALeqw8PCKaxFEHOtQPf8rjZN4Xxh8oGRff53GGNOZWPQ2bdMvHLFnCvtevdg/5+E 8aFFKcEkQG3p+V8qnxV/KVI4wi4jHq94Ua4we7szO0U4UCJRbabyAO09LPxDQWSB5e HJOYWf+m+6hmZFEaZCQc1/wmhtP9gD28bAfRpKeY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jeff Mahoney , David Sterba Subject: [PATCH 4.19 335/361] btrfs: keep trim from interfering with transaction commits Date: Sun, 11 Nov 2018 14:21:22 -0800 Message-Id: <20181111221700.234209394@linuxfoundation.org> X-Mailer: git-send-email 2.19.1 In-Reply-To: <20181111221619.915519183@linuxfoundation.org> References: <20181111221619.915519183@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.19-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jeff Mahoney commit fee7acc361314df6561208c2d3c0882d663dd537 upstream. Commit 499f377f49f08 (btrfs: iterate over unused chunk space in FITRIM) fixed free space trimming, but introduced latency when it was running. This is due to it pinning the transaction using both a incremented refcount and holding the commit root sem for the duration of a single trim operation. This was to ensure safety but it's unnecessary. We already hold the the chunk mutex so we know that the chunk we're using can't be allocated while we're trimming it. In order to check against chunks allocated already in this transaction, we need to check the pending chunks list. To to that safely without joining the transaction (or attaching than then having to commit it) we need to ensure that the dev root's commit root doesn't change underneath us and the pending chunk lists stays around until we're done with it. We can ensure the former by holding the commit root sem and the latter by pinning the transaction. We do this now, but the critical section covers the trim operation itself and we don't need to do that. This patch moves the pinning and unpinning logic into helpers and unpins the transaction after performing the search and check for pending chunks. Limiting the critical section of the transaction pinning improves the latency substantially on slower storage (e.g. image files over NFS). Fixes: 499f377f49f08 ("btrfs: iterate over unused chunk space in FITRIM") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Jeff Mahoney Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/extent-tree.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -10772,14 +10772,16 @@ int btrfs_error_unpin_extent_range(struc * We don't want a transaction for this since the discard may take a * substantial amount of time. We don't require that a transaction be * running, but we do need to take a running transaction into account - * to ensure that we're not discarding chunks that were released in - * the current transaction. + * to ensure that we're not discarding chunks that were released or + * allocated in the current transaction. * * Holding the chunks lock will prevent other threads from allocating * or releasing chunks, but it won't prevent a running transaction * from committing and releasing the memory that the pending chunks * list head uses. For that, we need to take a reference to the - * transaction. + * transaction and hold the commit root sem. We only need to hold + * it while performing the free space search since we have already + * held back allocations. */ static int btrfs_trim_free_extents(struct btrfs_device *device, u64 minlen, u64 *trimmed) @@ -10810,9 +10812,13 @@ static int btrfs_trim_free_extents(struc ret = mutex_lock_interruptible(&fs_info->chunk_mutex); if (ret) - return ret; + break; - down_read(&fs_info->commit_root_sem); + ret = down_read_killable(&fs_info->commit_root_sem); + if (ret) { + mutex_unlock(&fs_info->chunk_mutex); + break; + } spin_lock(&fs_info->trans_lock); trans = fs_info->running_transaction; @@ -10820,13 +10826,17 @@ static int btrfs_trim_free_extents(struc refcount_inc(&trans->use_count); spin_unlock(&fs_info->trans_lock); + if (!trans) + up_read(&fs_info->commit_root_sem); + ret = find_free_dev_extent_start(trans, device, minlen, start, &start, &len); - if (trans) + if (trans) { + up_read(&fs_info->commit_root_sem); btrfs_put_transaction(trans); + } if (ret) { - up_read(&fs_info->commit_root_sem); mutex_unlock(&fs_info->chunk_mutex); if (ret == -ENOSPC) ret = 0; @@ -10834,7 +10844,6 @@ static int btrfs_trim_free_extents(struc } ret = btrfs_issue_discard(device->bdev, start, len, &bytes); - up_read(&fs_info->commit_root_sem); mutex_unlock(&fs_info->chunk_mutex); if (ret)