From: green@linuxhacker.ru
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
devel@driverdev.osuosl.org,
Andreas Dilger <andreas.dilger@intel.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Li Xi <lixi@ddn.com>, Oleg Drokin <oleg.drokin@intel.com>
Subject: [PATCH 03/20] staging/lustre/ldlm: high load because of negative timeout
Date: Sun, 1 Feb 2015 21:52:02 -0500 [thread overview]
Message-ID: <1422845539-26742-4-git-send-email-green@linuxhacker.ru> (raw)
In-Reply-To: <1422845539-26742-1-git-send-email-green@linuxhacker.ru>
From: Li Xi <lixi@ddn.com>
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 <lixi@ddn.com>
Reviewed-on: http://review.whamcloud.com/11227
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5415
Reviewed-by: Dmitry Eremin <dmitry.eremin@intel.com>
Reviewed-by: Bobi Jam <bobijam@gmail.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
---
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
next prev parent reply other threads:[~2015-02-02 2:58 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-02 2:51 [PATCH 00/20] Lustre fixes green
2015-02-02 2:52 ` [PATCH 01/20] staging/lustre/ptlrpc: avoid list scan in ptlrpcd_check green
2015-02-02 2:52 ` [PATCH 02/20] staging/lustre/osc: split different type of IO green
2015-02-02 2:52 ` green [this message]
2015-02-02 2:52 ` [PATCH 04/20] staging/lustre/libcfs: fix illegal page access of tracefiled() green
2015-02-02 2:52 ` [PATCH 05/20] staging/lustre/obdclass: fix a race in recovery green
2015-02-02 2:52 ` [PATCH 06/20] staging/lustre: fix comparison between signed and unsigned green
2015-02-02 13:02 ` Dan Carpenter
2015-02-02 15:44 ` Greg Kroah-Hartman
2015-02-02 20:25 ` Oleg Drokin
2015-02-02 20:51 ` Greg Kroah-Hartman
2015-02-02 23:16 ` Oleg Drokin
2015-02-02 2:52 ` [PATCH 07/20] staging/lustre/lnet: peer aliveness status and NI status green
2015-02-02 2:52 ` [PATCH 08/20] staging/lustre/llite: to configure max_cached_mb correctly green
2015-02-02 2:52 ` [PATCH 09/20] staging/lustre/llite: remove llite proc root on init failure green
2015-02-02 2:52 ` [PATCH 10/20] staging/lustre/obdclass: Proper swabbing of llog_rec_tail green
2015-02-02 2:52 ` [PATCH 11/20] staging/lustre/lnet: portal spreading rotor should be unsigned green
2015-02-02 2:52 ` [PATCH 12/20] staging/lustre/obd: change type of cl_conn_count to size_t green
2015-02-07 9:30 ` Greg Kroah-Hartman
2015-02-02 2:52 ` [PATCH 13/20] staging/lustre/ptlrpc: hold rq_lock when modify rq_flags green
2015-02-02 2:52 ` [PATCH 14/20] staging/lustre/llite: Solve a race to access lli_has_smd in read case green
2015-02-02 2:52 ` [PATCH 15/20] staging/lustre/fld: refer to MDT0 for fld lookup in some cases green
2015-02-02 2:52 ` [PATCH 16/20] staging/lustre/libcfs: protect kkuc_groups from write access green
2015-02-02 2:52 ` [PATCH 17/20] staging/lustre/llite: Add exception entry check after radix_tree green
2015-02-02 2:52 ` [PATCH 18/20] staging/lustre/llite: don't add to page cache upon failure green
2015-02-02 2:52 ` [PATCH 19/20] staging/lustre/clio: Do not allow group locks with gid 0 green
2015-02-02 2:52 ` [PATCH 20/20] staging/lustre/mdc: Initialize req in mdc_enqueue for !it case green
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1422845539-26742-4-git-send-email-green@linuxhacker.ru \
--to=green@linuxhacker.ru \
--cc=andreas.dilger@intel.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lixi@ddn.com \
--cc=oleg.drokin@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox