From: Patrick Farrell <paf@cray.com>
To: NeilBrown <neilb@suse.com>, Oleg Drokin <oleg.drokin@intel.com>,
Andreas Dilger <andreas.dilger@intel.com>,
James Simmons <jsimmons@infradead.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
lustre <lustre-devel@lists.lustre.org>
Subject: [lustre-devel] [PATCH 11/16] staging: lustre: make polling loop in ptlrpc_unregister_bulk more obvious
Date: Mon, 18 Dec 2017 21:03:54 +0000 [thread overview]
Message-ID: <D65D88CA.C5E2F%paf@cray.com> (raw)
In-Reply-To: <151358148020.5099.4047116902359752959.stgit@noble>
This probably shouldn?t contribute to load, it?s often (mostly?) run out
of the ptlrpcd daemons.
- Patrick
On 12/18/17, 1:18 AM, "lustre-devel on behalf of NeilBrown"
<lustre-devel-bounces at lists.lustre.org on behalf of neilb@suse.com> wrote:
>This use of l_wait_event() is a polling loop that re-checks
>every second. Make this more obvious with a while loop
>and wait_event_timeout().
>
>Signed-off-by: NeilBrown <neilb@suse.com>
>---
> drivers/staging/lustre/lustre/ptlrpc/niobuf.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/staging/lustre/lustre/ptlrpc/niobuf.c
>b/drivers/staging/lustre/lustre/ptlrpc/niobuf.c
>index 0c2ded721c49..5606c8f01b5b 100644
>--- a/drivers/staging/lustre/lustre/ptlrpc/niobuf.c
>+++ b/drivers/staging/lustre/lustre/ptlrpc/niobuf.c
>@@ -229,7 +229,6 @@ int ptlrpc_unregister_bulk(struct ptlrpc_request
>*req, int async)
> {
> struct ptlrpc_bulk_desc *desc = req->rq_bulk;
> wait_queue_head_t *wq;
>- struct l_wait_info lwi;
> int rc;
>
> LASSERT(!in_interrupt()); /* might sleep */
>@@ -246,7 +245,7 @@ int ptlrpc_unregister_bulk(struct ptlrpc_request
>*req, int async)
>
> /* the unlink ensures the callback happens ASAP and is the last
> * one. If it fails, it must be because completion just happened,
>- * but we must still l_wait_event() in this case to give liblustre
>+ * but we must still wait_event() in this case to give liblustre
> * a chance to run client_bulk_callback()
> */
> mdunlink_iterate_helper(desc->bd_mds, desc->bd_md_max_brw);
>@@ -270,15 +269,16 @@ int ptlrpc_unregister_bulk(struct ptlrpc_request
>*req, int async)
> /* Network access will complete in finite time but the HUGE
> * timeout lets us CWARN for visibility of sluggish LNDs
> */
>- lwi = LWI_TIMEOUT_INTERVAL(LONG_UNLINK * HZ,
>- HZ, NULL, NULL);
>- rc = l_wait_event(*wq, !ptlrpc_client_bulk_active(req), &lwi);
>- if (rc == 0) {
>+ int cnt = 0;
>+ while (cnt < LONG_UNLINK &&
>+ (rc = wait_event_timeout(*wq, !ptlrpc_client_bulk_active(req),
>+ HZ)) == 0)
>+ cnt += 1;
>+ if (rc > 0) {
> ptlrpc_rqphase_move(req, req->rq_next_phase);
> return 1;
> }
>
>- LASSERT(rc == -ETIMEDOUT);
> DEBUG_REQ(D_WARNING, req, "Unexpectedly long timeout: desc %p",
> desc);
> }
>
>
>_______________________________________________
>lustre-devel mailing list
>lustre-devel at lists.lustre.org
>http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
WARNING: multiple messages have this Message-ID (diff)
From: Patrick Farrell <paf@cray.com>
To: NeilBrown <neilb@suse.com>, Oleg Drokin <oleg.drokin@intel.com>,
"Andreas Dilger" <andreas.dilger@intel.com>,
James Simmons <jsimmons@infradead.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
lustre <lustre-devel@lists.lustre.org>
Subject: Re: [lustre-devel] [PATCH 11/16] staging: lustre: make polling loop in ptlrpc_unregister_bulk more obvious
Date: Mon, 18 Dec 2017 21:03:54 +0000 [thread overview]
Message-ID: <D65D88CA.C5E2F%paf@cray.com> (raw)
In-Reply-To: <151358148020.5099.4047116902359752959.stgit@noble>
This probably shouldn¹t contribute to load, it¹s often (mostly?) run out
of the ptlrpcd daemons.
- Patrick
On 12/18/17, 1:18 AM, "lustre-devel on behalf of NeilBrown"
<lustre-devel-bounces@lists.lustre.org on behalf of neilb@suse.com> wrote:
>This use of l_wait_event() is a polling loop that re-checks
>every second. Make this more obvious with a while loop
>and wait_event_timeout().
>
>Signed-off-by: NeilBrown <neilb@suse.com>
>---
> drivers/staging/lustre/lustre/ptlrpc/niobuf.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/staging/lustre/lustre/ptlrpc/niobuf.c
>b/drivers/staging/lustre/lustre/ptlrpc/niobuf.c
>index 0c2ded721c49..5606c8f01b5b 100644
>--- a/drivers/staging/lustre/lustre/ptlrpc/niobuf.c
>+++ b/drivers/staging/lustre/lustre/ptlrpc/niobuf.c
>@@ -229,7 +229,6 @@ int ptlrpc_unregister_bulk(struct ptlrpc_request
>*req, int async)
> {
> struct ptlrpc_bulk_desc *desc = req->rq_bulk;
> wait_queue_head_t *wq;
>- struct l_wait_info lwi;
> int rc;
>
> LASSERT(!in_interrupt()); /* might sleep */
>@@ -246,7 +245,7 @@ int ptlrpc_unregister_bulk(struct ptlrpc_request
>*req, int async)
>
> /* the unlink ensures the callback happens ASAP and is the last
> * one. If it fails, it must be because completion just happened,
>- * but we must still l_wait_event() in this case to give liblustre
>+ * but we must still wait_event() in this case to give liblustre
> * a chance to run client_bulk_callback()
> */
> mdunlink_iterate_helper(desc->bd_mds, desc->bd_md_max_brw);
>@@ -270,15 +269,16 @@ int ptlrpc_unregister_bulk(struct ptlrpc_request
>*req, int async)
> /* Network access will complete in finite time but the HUGE
> * timeout lets us CWARN for visibility of sluggish LNDs
> */
>- lwi = LWI_TIMEOUT_INTERVAL(LONG_UNLINK * HZ,
>- HZ, NULL, NULL);
>- rc = l_wait_event(*wq, !ptlrpc_client_bulk_active(req), &lwi);
>- if (rc == 0) {
>+ int cnt = 0;
>+ while (cnt < LONG_UNLINK &&
>+ (rc = wait_event_timeout(*wq, !ptlrpc_client_bulk_active(req),
>+ HZ)) == 0)
>+ cnt += 1;
>+ if (rc > 0) {
> ptlrpc_rqphase_move(req, req->rq_next_phase);
> return 1;
> }
>
>- LASSERT(rc == -ETIMEDOUT);
> DEBUG_REQ(D_WARNING, req, "Unexpectedly long timeout: desc %p",
> desc);
> }
>
>
>_______________________________________________
>lustre-devel mailing list
>lustre-devel@lists.lustre.org
>http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
next prev parent reply other threads:[~2017-12-18 21:03 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-18 7:17 [lustre-devel] [PATCH SERIES 5: 00/16] staging: lustre: use standard wait_event macros NeilBrown
2017-12-18 7:17 ` NeilBrown
2017-12-18 7:17 ` [lustre-devel] [PATCH 04/16] staging: lustre: use wait_event_timeout() where appropriate NeilBrown
2017-12-18 7:17 ` NeilBrown
2017-12-18 20:23 ` [lustre-devel] " Patrick Farrell
2017-12-18 20:23 ` Patrick Farrell
2017-12-18 7:17 ` [lustre-devel] [PATCH 01/16] staging: lustre: discard SVC_SIGNAL and related functions NeilBrown
2017-12-18 7:17 ` NeilBrown
2017-12-18 7:17 ` [lustre-devel] [PATCH 02/16] staging: lustre: replace simple cases of l_wait_event() with wait_event() NeilBrown
2017-12-18 7:17 ` NeilBrown
2017-12-18 17:48 ` [lustre-devel] " Patrick Farrell
2017-12-18 17:48 ` Patrick Farrell
2017-12-18 21:37 ` NeilBrown
2017-12-18 21:37 ` NeilBrown
2017-12-18 18:03 ` Patrick Farrell
2017-12-18 18:03 ` Patrick Farrell
2017-12-19 10:37 ` Dilger, Andreas
2017-12-19 10:37 ` Dilger, Andreas
2017-12-19 20:49 ` NeilBrown
2017-12-19 20:49 ` NeilBrown
2017-12-18 7:17 ` [lustre-devel] [PATCH 03/16] staging: lustre: discard cfs_time_seconds() NeilBrown
2017-12-18 7:17 ` NeilBrown
2017-12-18 7:18 ` [lustre-devel] [PATCH 06/16] staging: lustre: simplify l_wait_event when intr handler but no timeout NeilBrown
2017-12-18 7:18 ` NeilBrown
2017-12-18 7:18 ` [lustre-devel] [PATCH 15/16] staging: lustre: use explicit poll loop in ptlrpc_unregister_reply NeilBrown
2017-12-18 7:18 ` NeilBrown
2017-12-18 21:09 ` [lustre-devel] " Patrick Farrell
2017-12-18 21:09 ` Patrick Farrell
2017-12-18 7:18 ` [lustre-devel] [PATCH 09/16] staging: lustre: simplify waiting in ptlrpc_invalidate_import() NeilBrown
2017-12-18 7:18 ` NeilBrown
2017-12-18 7:18 ` [lustre-devel] [PATCH 13/16] staging: lustre: improve waiting in sptlrpc_req_refresh_ctx NeilBrown
2017-12-18 7:18 ` NeilBrown
2017-12-18 7:18 ` [lustre-devel] [PATCH 16/16] staging: lustre: remove l_wait_event from ptlrpc_set_wait NeilBrown
2017-12-18 7:18 ` NeilBrown
2017-12-18 7:18 ` [lustre-devel] [PATCH 10/16] staging: lustre: remove back_to_sleep() and use loops NeilBrown
2017-12-18 7:18 ` NeilBrown
2017-12-18 7:18 ` [lustre-devel] [PATCH 14/16] staging: lustre: use explicit poll loop in ptlrpc_service_unlink_rqbd NeilBrown
2017-12-18 7:18 ` NeilBrown
2017-12-18 7:18 ` [lustre-devel] [PATCH 08/16] staging: lustre: open code polling loop instead of using l_wait_event() NeilBrown
2017-12-18 7:18 ` NeilBrown
2017-12-18 20:55 ` [lustre-devel] " Patrick Farrell
2017-12-18 20:55 ` Patrick Farrell
2017-12-18 7:18 ` [lustre-devel] [PATCH 07/16] staging: lustre: simplify waiting in ldlm_completion_ast() NeilBrown
2017-12-18 7:18 ` NeilBrown
2017-12-18 7:18 ` [lustre-devel] [PATCH 12/16] staging: lustre: use wait_event_timeout in ptlrpcd() NeilBrown
2017-12-18 7:18 ` NeilBrown
2017-12-18 7:18 ` [lustre-devel] [PATCH 05/16] staging: lustre: introduce and use l_wait_event_abortable() NeilBrown
2017-12-18 7:18 ` NeilBrown
2017-12-18 7:18 ` [lustre-devel] [PATCH 11/16] staging: lustre: make polling loop in ptlrpc_unregister_bulk more obvious NeilBrown
2017-12-18 7:18 ` NeilBrown
2017-12-18 21:03 ` Patrick Farrell [this message]
2017-12-18 21:03 ` [lustre-devel] " Patrick Farrell
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=D65D88CA.C5E2F%paf@cray.com \
--to=paf@cray.com \
--cc=andreas.dilger@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=jsimmons@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lustre-devel@lists.lustre.org \
--cc=neilb@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.