From patchwork Thu Sep 2 16:44:12 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shaoying Xu X-Patchwork-Id: 1523865 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=amazon.com header.i=@amazon.com header.a=rsa-sha256 header.s=amazon201209 header.b=MSL6/WWj; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=linux-ext4-owner@vger.kernel.org; receiver=) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by ozlabs.org (Postfix) with ESMTP id 4H0mwk0Cd6z9sCD for ; Fri, 3 Sep 2021 02:44:22 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346377AbhIBQpT (ORCPT ); Thu, 2 Sep 2021 12:45:19 -0400 Received: from smtp-fw-80006.amazon.com ([99.78.197.217]:1921 "EHLO smtp-fw-80006.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240292AbhIBQpO (ORCPT ); Thu, 2 Sep 2021 12:45:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1630601057; x=1662137057; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version; bh=MzJcUtfc7iPoM8SpKJzbe6uipwEa0d0bW+92yrWo/JI=; b=MSL6/WWjz64zqFTG/JPub7febH0ZKZ5ZYXeasuIdv/iwenfqiB+Al29A RT99yfZuzQuqSaUhq5NEu5KEIYgQrha05uf8/0rHzQFfIJrbe1+JsYX/Q Qgh7/QqvzTdEpbuvPY5kws2CYQ4j2FOo4Ip+zx8iupqUqNDw6HI6/W16h I=; X-IronPort-AV: E=Sophos;i="5.85,262,1624320000"; d="scan'208";a="24073115" Received: from pdx4-co-svc-p1-lb2-vlan3.amazon.com (HELO email-inbound-relay-1a-67b371d8.us-east-1.amazon.com) ([10.25.36.214]) by smtp-border-fw-80006.pdx80.corp.amazon.com with ESMTP; 02 Sep 2021 16:44:16 +0000 Received: from EX13MTAUWB001.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan2.iad.amazon.com [10.40.163.34]) by email-inbound-relay-1a-67b371d8.us-east-1.amazon.com (Postfix) with ESMTPS id 6F54CA1DDC; Thu, 2 Sep 2021 16:44:14 +0000 (UTC) Received: from EX13D21UWB001.ant.amazon.com (10.43.161.108) by EX13MTAUWB001.ant.amazon.com (10.43.161.207) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Thu, 2 Sep 2021 16:44:13 +0000 Received: from EX13MTAUEB002.ant.amazon.com (10.43.60.12) by EX13D21UWB001.ant.amazon.com (10.43.161.108) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Thu, 2 Sep 2021 16:44:13 +0000 Received: from dev-dsk-shaoyi-2b-c0ca772a.us-west-2.amazon.com (172.22.152.76) by mail-relay.amazon.com (10.43.60.234) with Microsoft SMTP Server id 15.0.1497.23 via Frontend Transport; Thu, 2 Sep 2021 16:44:12 +0000 Received: by dev-dsk-shaoyi-2b-c0ca772a.us-west-2.amazon.com (Postfix, from userid 13116433) id 8D41A41A9E; Thu, 2 Sep 2021 16:44:12 +0000 (UTC) From: Shaoying Xu To: , CC: , , , Subject: [PATCH 1/1] ext4: fix lazy initialization next schedule time computation in more granular unit Date: Thu, 2 Sep 2021 16:44:12 +0000 Message-ID: <20210902164412.9994-2-shaoyi@amazon.com> X-Mailer: git-send-email 2.16.6 In-Reply-To: <20210902164412.9994-1-shaoyi@amazon.com> References: <20210902164412.9994-1-shaoyi@amazon.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Ext4 file system has default lazy inode table initialization setup once it is mounted. However, it has issue on computing the next schedule time that makes the timeout same amount in jiffies but different real time in secs if with various HZ values. Therefore, fix by measuring the current time in a more granular unit nanoseconds and make the next schedule time independent of the HZ value. Fixes: bfff68738f1c ("ext4: add support for lazy inode table initialization") Signed-off-by: Shaoying Xu Cc: stable@vger.kernel.org --- fs/ext4/super.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/fs/ext4/super.c b/fs/ext4/super.c index dfa09a277b56..399cbe9c14a8 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -3421,9 +3421,9 @@ static int ext4_run_li_request(struct ext4_li_request *elr) struct super_block *sb = elr->lr_super; ext4_group_t ngroups = EXT4_SB(sb)->s_groups_count; ext4_group_t group = elr->lr_next_group; - unsigned long timeout = 0; unsigned int prefetch_ios = 0; int ret = 0; + u64 start_time; if (elr->lr_mode == EXT4_LI_MODE_PREFETCH_BBITMAP) { elr->lr_next_group = ext4_mb_prefetch(sb, group, @@ -3460,14 +3460,13 @@ static int ext4_run_li_request(struct ext4_li_request *elr) ret = 1; if (!ret) { - timeout = jiffies; + start_time = ktime_get_real_ns(); ret = ext4_init_inode_table(sb, group, elr->lr_timeout ? 0 : 1); trace_ext4_lazy_itable_init(sb, group); if (elr->lr_timeout == 0) { - timeout = (jiffies - timeout) * - EXT4_SB(elr->lr_super)->s_li_wait_mult; - elr->lr_timeout = timeout; + elr->lr_timeout = nsecs_to_jiffies((ktime_get_real_ns() - start_time) * + EXT4_SB(elr->lr_super)->s_li_wait_mult); } elr->lr_next_sched = jiffies + elr->lr_timeout; elr->lr_next_group = group + 1;