Received: by 2002:a25:b323:0:0:0:0:0 with SMTP id l35csp1808870ybj; Sun, 22 Sep 2019 12:24:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqxdaduW+9xTYe1iAWykD7UWpGp5giQWkT7n5aUONC32srzp/7t9sg/kVr+UEJIdYcUnw4IB X-Received: by 2002:a17:906:5fc4:: with SMTP id k4mr27617253ejv.300.1569180272489; Sun, 22 Sep 2019 12:24:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569180272; cv=none; d=google.com; s=arc-20160816; b=SgUoCYXBCrKvE8dVHLx+Qg9x/ZEcahLX3L0dM9cfXgLaqUU3iQZmTBIjxqN5VFikMo 8XLIyuoPfq1kAvh332oxiEFVivqJNeTq4XVM33FF/1pFZVRLIja4aAgo5szzCceJWAC7 a/meoLCJBKHv/+VQRCk58iRv3zLWCA/hEb2H3ufH57ndZtE8jg8hk+pPLO+PCzOgKCVS TbuXHKXpoJYYT4Uk0YKjaG+sf18q4hzh+4Qipi3X/sCxx/6fDYng/kybU6FiZe5touFp NBSt5uf5/Um+HTIroUupS1cnku1mlpPUQSCTLcLxH163/vi8Ru4hHnhOMtgCmfq07Iel 9GzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:to:from; bh=vZFtEXW7I5mgBVQNGc2GfvCVBh5XSt4Cuo0AWshti7s=; b=NVNmrGRJawfTgKRe0VcXUP0RQLuPmJj90r/BvK8Gb3ijoWF9yIDcs48k9xP6Mrhuxp St3l1L7i3+PqVqktvxAc/ZCezfkSLgqpqsTDmRt4AYO+HUTdLAk9SXrhLo4J8WIWRBWS GC0Jc9cTCPP3AlYMuaFQciksnj/rkgnMmx0VtMatRwmI6qFQtA/lOM6HOOaK+qCD2e8f XqZhLj0fdRSS7HOqVBcghenfm+TxQYCP39UzpunLTptx8pVSEPCmOD+L/oB+yEbw1tgi yMR/Y+KlJRtoGkpy0f32VA2u5mEyeKb3bVhDVlDKRUchQ0p1x3eL4IZfS5ARWUPokbdr Tdjg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ch10si4010852ejb.89.2019.09.22.12.24.07; Sun, 22 Sep 2019 12:24:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727597AbfIVHFR (ORCPT + 99 others); Sun, 22 Sep 2019 03:05:17 -0400 Received: from out30-44.freemail.mail.aliyun.com ([115.124.30.44]:47010 "EHLO out30-44.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727548AbfIVHFR (ORCPT ); Sun, 22 Sep 2019 03:05:17 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R111e4;CH=green;DM=||false|;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04420;MF=xiaoguang.wang@linux.alibaba.com;NM=1;PH=DS;RN=1;SR=0;TI=SMTPD_---0Td0uxnO_1569135907; Received: from localhost(mailfrom:xiaoguang.wang@linux.alibaba.com fp:SMTPD_---0Td0uxnO_1569135907) by smtp.aliyun-inc.com(127.0.0.1); Sun, 22 Sep 2019 15:05:11 +0800 From: Xiaoguang Wang To: linux-ext4@vger.kernel.org Subject: [PATCH 0/2] make jbd2 support checkpoint asynchronously Date: Sun, 22 Sep 2019 15:04:57 +0800 Message-Id: <20190922070459.39797-1-xiaoguang.wang@linux.alibaba.com> X-Mailer: git-send-email 2.14.4.44.g2045bb6 Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org In current jbd2's implemention, jbd2 won't reclaim journal space unless free journal space is lower than specified threshold, see logic in add_transaction_credits(): write_lock(&journal->j_state_lock); if (jbd2_log_space_left(journal) < jbd2_space_needed(journal)) __jbd2_log_wait_for_space(journal); write_unlock(&journal->j_state_lock); Indeed with this logic, we can also have many transactions queued to be checkpointd, which means these transactions still occupy jbd2 space. Journal space is somewhat like a global lock. In high concurrency case, if many tasks contend for journal credits, they will easily be blocked in waitting for free journal space, so I wonder whether we can reclaim journal space asynchronously when free space is lower than a specified threshold, to avoid that all applications are stalled at the same time. This will be more useful in high speed store, journal space will be reclaimed in background quickly, and applications will less likely to be stucked, to improve this case, we use workqueue to queue a work in background to reclaim journal space. I have used fs_mark to have performance test, in most cases, we have performance improvement, in specific case, we can have above 14.4% improvement, see patch "ext4: add async_checkpoint mount option" for detailed test info. Xiaoguang Wang (2): jbd2: checkpoint asynchronously when free journal space is lower than threshold ext4: add async_checkpoint mount option fs/ext4/ext4.h | 2 ++ fs/ext4/super.c | 71 +++++++++++++++++++++++++++++++++++++++++++++++++++ fs/jbd2/checkpoint.c | 28 +++++++++++++++++--- fs/jbd2/journal.c | 15 +++++++++-- fs/jbd2/transaction.c | 16 ++++++++++++ include/linux/jbd2.h | 48 +++++++++++++++++++++++++++++++++- 6 files changed, 174 insertions(+), 6 deletions(-) -- 1.8.3.1