From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932564AbbBBC6C (ORCPT ); Sun, 1 Feb 2015 21:58:02 -0500 Received: from linuxhacker.ru ([217.76.32.60]:59785 "EHLO fiona.linuxhacker.ru" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1754644AbbBBCxD (ORCPT ); Sun, 1 Feb 2015 21:53:03 -0500 From: green@linuxhacker.ru To: Greg Kroah-Hartman , devel@driverdev.osuosl.org, Andreas Dilger Cc: Linux Kernel Mailing List , Li Xi , Oleg Drokin Subject: [PATCH 03/20] staging/lustre/ldlm: high load because of negative timeout Date: Sun, 1 Feb 2015 21:52:02 -0500 Message-Id: <1422845539-26742-4-git-send-email-green@linuxhacker.ru> X-Mailer: git-send-email 2.1.0 In-Reply-To: <1422845539-26742-1-git-send-email-green@linuxhacker.ru> References: <1422845539-26742-1-git-send-email-green@linuxhacker.ru> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Li Xi When the time of LRU resizing exceeds waiting period of recalculation, the ldlm daemon will keep on resizing without any interval of rest. That will cause high CPU load. This patch fixes the problem by setting the recalculation timestamp after LRU resizing finishes rather than before it. What is more, an interval of one second is enforced between each recalculation. Signed-off-by: Li Xi Reviewed-on: http://review.whamcloud.com/11227 Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5415 Reviewed-by: Dmitry Eremin Reviewed-by: Bobi Jam Reviewed-by: Lai Siyao Signed-off-by: Oleg Drokin --- drivers/staging/lustre/lustre/ldlm/ldlm_pool.c | 32 +++++++++++++++++++++----- 1 file changed, 26 insertions(+), 6 deletions(-) diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c b/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c index 142b3dd..d20d277 100644 --- a/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c @@ -470,6 +470,7 @@ static void ldlm_cli_pool_pop_slv(struct ldlm_pool *pl) static int ldlm_cli_pool_recalc(struct ldlm_pool *pl) { time_t recalc_interval_sec; + int ret; recalc_interval_sec = get_seconds() - pl->pl_recalc_time; if (recalc_interval_sec < pl->pl_recalc_period) @@ -490,16 +491,15 @@ static int ldlm_cli_pool_recalc(struct ldlm_pool *pl) */ ldlm_cli_pool_pop_slv(pl); - pl->pl_recalc_time = get_seconds(); - lprocfs_counter_add(pl->pl_stats, LDLM_POOL_TIMING_STAT, - recalc_interval_sec); spin_unlock(&pl->pl_lock); /* * Do not cancel locks in case lru resize is disabled for this ns. */ - if (!ns_connect_lru_resize(ldlm_pl2ns(pl))) - return 0; + if (!ns_connect_lru_resize(ldlm_pl2ns(pl))) { + ret = 0; + goto out; + } /* * In the time of canceling locks on client we do not need to maintain @@ -507,7 +507,19 @@ static int ldlm_cli_pool_recalc(struct ldlm_pool *pl) * It may be called when SLV has changed much, this is why we do not * take into account pl->pl_recalc_time here. */ - return ldlm_cancel_lru(ldlm_pl2ns(pl), 0, LCF_ASYNC, LDLM_CANCEL_LRUR); + ret = ldlm_cancel_lru(ldlm_pl2ns(pl), 0, LCF_ASYNC, LDLM_CANCEL_LRUR); + +out: + spin_lock(&pl->pl_lock); + /* + * Time of LRU resizing might be longer than period, + * so update after LRU resizing rather than before it. + */ + pl->pl_recalc_time = get_seconds(); + lprocfs_counter_add(pl->pl_stats, LDLM_POOL_TIMING_STAT, + recalc_interval_sec); + spin_unlock(&pl->pl_lock); + return ret; } /** @@ -591,6 +603,14 @@ int ldlm_pool_recalc(struct ldlm_pool *pl) } recalc_interval_sec = pl->pl_recalc_time - get_seconds() + pl->pl_recalc_period; + if (recalc_interval_sec <= 0) { + /* Prevent too frequent recalculation. */ + CDEBUG(D_DLMTRACE, "Negative interval(%ld), " + "too short period(%ld)", + recalc_interval_sec, + pl->pl_recalc_period); + recalc_interval_sec = 1; + } return recalc_interval_sec; } -- 2.1.0