From patchwork Wed Mar 12 01:28:24 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 3815171 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 19627BF540 for ; Wed, 12 Mar 2014 01:30:51 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 38F3C201FD for ; Wed, 12 Mar 2014 01:30:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4AC4820254 for ; Wed, 12 Mar 2014 01:30:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756279AbaCLBap (ORCPT ); Tue, 11 Mar 2014 21:30:45 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:40669 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756477AbaCLB26 (ORCPT ); Tue, 11 Mar 2014 21:28:58 -0400 Received: by mail-wi0-f172.google.com with SMTP id hi5so1719511wib.11 for ; Tue, 11 Mar 2014 18:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=crFdvpaQFJHEs/NCi6MVSAJ42t6+S3AjW2Q+94UyT2I=; b=V9QVFCri3BZn+aY9c+/Itx19yfasNvJjZgUGnCOpCRQb5DqHpjrKjtjBMxTGBg8ywh U9Up0d77LtoPAHqXiCivG+rQyCw/KSb7HYonrzxnbPQBUl5qbiMaZV77zvGHOCzIdtTn LfRegB8r94VIIBF5/xi6lXdM7iDAPgO/lB6e+y8tfrM3/3bg6qRvhcm982iacpvlHB1x 81GcdFBRb6oYDkVwymeGadiQVWESFx5QdjMT4KPtXH/uXIM9SSCYRNiiTNPPAozseu+u 9xOBlwqD/P6H9ePopTydX68xLTlRQ5WmYKjJBhgCE6e2fVfEpH7IZP2co1n0SaFua34Z Lyrg== X-Received: by 10.180.100.72 with SMTP id ew8mr5473750wib.16.1394587737208; Tue, 11 Mar 2014 18:28:57 -0700 (PDT) Received: from storm-desktop.lan (bl10-252-34.dsl.telepac.pt. [85.243.252.34]) by mx.google.com with ESMTPSA id dk9sm65657888wjb.4.2014.03.11.18.28.55 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Mar 2014 18:28:56 -0700 (PDT) From: Filipe David Borba Manana To: linux-btrfs@vger.kernel.org Cc: Filipe David Borba Manana Subject: [PATCH 1/2 v2] Btrfs: less fs tree lock contention when using autodefrag Date: Wed, 12 Mar 2014 01:28:24 +0000 Message-Id: <1394587704-22578-1-git-send-email-fdmanana@gmail.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1394546175-7370-1-git-send-email-fdmanana@gmail.com> References: <1394546175-7370-1-git-send-email-fdmanana@gmail.com> Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP When finding new extents during an autodefrag, don't do so many fs tree lookups to find an extent with a size smaller then the target treshold. Instead, after each fs tree forward search immediately unlock upper levels and process the entire leaf while holding a read lock on the leaf, since our leaf processing is very fast. This reduces lock contention, allowing for higher concurrency when other tasks want to write/update items related to other inodes in the fs tree, as we're not holding read locks on upper tree levels while processing the leaf and we do less tree searches. Test: sysbench --test=fileio --file-num=512 --file-total-size=16G \ --file-test-mode=rndrw --num-threads=32 --file-block-size=32768 \ --file-rw-ratio=3 --file-io-mode=sync --max-time=1800 \ --max-requests=10000000000 [prepare|run] (fileystem mounted with -o autodefrag, averages of 5 runs) Before this change: 58.852Mb/sec throughtput, read 77.589Gb, written 25.863Gb After this change: 63.034Mb/sec throughtput, read 83.102Gb, written 27.701Gb Test machine: quad core intel i5-3570K, 32Gb of RAM, SSD. Signed-off-by: Filipe David Borba Manana --- V2: Added missing path->keep_locks reset, which made the unlock_up_safe call be a noop. And updated commit message test numbers. fs/btrfs/ioctl.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index e174770..6ab95cc 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -935,12 +935,14 @@ static int find_new_extents(struct btrfs_root *root, min_key.type = BTRFS_EXTENT_DATA_KEY; min_key.offset = *off; - path->keep_locks = 1; - while (1) { + path->keep_locks = 1; ret = btrfs_search_forward(root, &min_key, path, newer_than); if (ret != 0) goto none; + path->keep_locks = 0; + btrfs_unlock_up_safe(path, 1); +process_slot: if (min_key.objectid != ino) goto none; if (min_key.type != BTRFS_EXTENT_DATA_KEY) @@ -959,6 +961,12 @@ static int find_new_extents(struct btrfs_root *root, return 0; } + path->slots[0]++; + if (path->slots[0] < btrfs_header_nritems(leaf)) { + btrfs_item_key_to_cpu(leaf, &min_key, path->slots[0]); + goto process_slot; + } + if (min_key.offset == (u64)-1) goto none;