From: Alexander Aring <aahringo@redhat.com>
To: teigland@redhat.com
Cc: gfs2@lists.linux.dev, aahringo@redhat.com
Subject: [PATCHv4 dlm/next 15/15] dlm: do dlm message processing in softirq context
Date: Tue, 2 Apr 2024 15:18:10 -0400 [thread overview]
Message-ID: <20240402191810.1932939-16-aahringo@redhat.com> (raw)
In-Reply-To: <20240402191810.1932939-1-aahringo@redhat.com>
This patch moves the dlm message processing from a ordered workqueue
context to a ordered softirq context. Later we want to call the user
defined ast/bast callbacks directly inside the dlm message processing
context instead of doing an additional context switch to the exisiting
callback workqueue. This should slightly improve the dlm message parsing
behaviour. There are two main reasons why to change to this behaviour:
1.
Allow fewer scheduling possibilities for dlm message parsing context.
This should deliver faster DLM user responses to ast/bast callbacks.
Fewer interrupting of lock requests processing that might trigger a
new lock request avoids situations that we don't finish lock
requests. In future the DLM callback workqueue can be disabled by
a kernel lockspace flag to signal the DLM kernel user is capable
of exectuing the callbacks in softirq context. If this flag is set,
the dlm processing gets rid of an additional queue_work() context
switch that should take more advantage about the new softirq context
because the last preemption possibility is removed from the message
processing context.
2. Bringing the ast/callback callback to softirq context that the use is
aware it should not block into this context. Later patches will
introduce a per lockspace flag to signal that the user is capable to
handling these callbacks in softirq context to solve backwards
compatibility. Handling the callback in the receive part and not in a
workqueue will reduce a unnecessarily context switch. Signaling the
user that the callback context can run in a softirq context will
force that the user of DLM will not sleep in such context and leave
it "fast as possible" again.
Futher patches will unveil more improvements to switch to a per message
softirq parsing context. Especially if we getting DLM in a state that we
can allow concurrent message parsing.
Signed-off-by: Alexander Aring <aahringo@redhat.com>
---
fs/dlm/lowcomms.c | 28 ++++++++++++++++++++--------
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
index 444dc858c4a4..6b8078085e56 100644
--- a/fs/dlm/lowcomms.c
+++ b/fs/dlm/lowcomms.c
@@ -204,6 +204,7 @@ static void process_dlm_messages(struct work_struct *work);
static DECLARE_WORK(process_work, process_dlm_messages);
static DEFINE_SPINLOCK(processqueue_lock);
static bool process_dlm_messages_pending;
+static DECLARE_WAIT_QUEUE_HEAD(processqueue_wq);
static atomic_t processqueue_count;
static LIST_HEAD(processqueue);
@@ -877,7 +878,8 @@ static void process_dlm_messages(struct work_struct *work)
}
list_del(&pentry->list);
- atomic_dec(&processqueue_count);
+ if (atomic_dec_and_test(&processqueue_count))
+ wake_up(&processqueue_wq);
spin_unlock_bh(&processqueue_lock);
for (;;) {
@@ -895,7 +897,8 @@ static void process_dlm_messages(struct work_struct *work)
}
list_del(&pentry->list);
- atomic_dec(&processqueue_count);
+ if (atomic_dec_and_test(&processqueue_count))
+ wake_up(&processqueue_wq);
spin_unlock_bh(&processqueue_lock);
}
}
@@ -1511,7 +1514,20 @@ static void process_recv_sockets(struct work_struct *work)
/* CF_RECV_PENDING cleared */
break;
case DLM_IO_FLUSH:
- flush_workqueue(process_workqueue);
+ /* we can't flush the process_workqueue here because a
+ * WQ_MEM_RECLAIM workequeue can occurr a deadlock for a non
+ * WQ_MEM_RECLAIM workqueue such as process_workqueue. Instead
+ * we have a waitqueue to wait until all messages are
+ * processed.
+ *
+ * This handling is only necessary to backoff the sender and
+ * not queue all messages from the socket layer into DLM
+ * processqueue. When DLM is capable to parse multiple messages
+ * on an e.g. per socket basis this handling can might be
+ * removed. Especially in a message burst we are too slow to
+ * process messages and the queue will fill up memory.
+ */
+ wait_event(processqueue_wq, !atomic_read(&processqueue_count));
fallthrough;
case DLM_IO_RESCHED:
cond_resched();
@@ -1701,11 +1717,7 @@ static int work_start(void)
return -ENOMEM;
}
- /* ordered dlm message process queue,
- * should be converted to a tasklet
- */
- process_workqueue = alloc_ordered_workqueue("dlm_process",
- WQ_HIGHPRI | WQ_MEM_RECLAIM);
+ process_workqueue = alloc_workqueue("dlm_process", WQ_HIGHPRI | WQ_BH, 0);
if (!process_workqueue) {
log_print("can't start dlm_process");
destroy_workqueue(io_workqueue);
--
2.43.0
prev parent reply other threads:[~2024-04-02 19:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-02 19:17 [PATCHv4 dlm/next 00/15] dlm: bring message parsing to softirq context Alexander Aring
2024-04-02 19:17 ` [PATCHv4 dlm/next 01/15] dlm: Simplify the allocation of slab caches in dlm_lowcomms_msg_cache_create Alexander Aring
2024-04-02 19:17 ` [PATCHv4 dlm/next 02/15] dlm: remove allocation parameter in msg allocation Alexander Aring
2024-04-02 19:17 ` [PATCHv4 dlm/next 03/15] dlm: switch to GFP_ATOMIC in dlm allocations Alexander Aring
2024-04-02 19:17 ` [PATCHv4 dlm/next 04/15] dlm: move root_list functionality to recover.c Alexander Aring
2024-04-02 19:18 ` [PATCHv4 dlm/next 05/15] dlm: move master dir dump to own list Alexander Aring
2024-04-02 19:18 ` [PATCHv4 dlm/next 06/15] dlm: move root_list to ls_recover() stack Alexander Aring
2024-04-02 19:18 ` [PATCHv4 dlm/next 07/15] dlm: implement directory dump context Alexander Aring
2024-04-02 19:18 ` [PATCHv4 dlm/next 08/15] dlm: drop holding waiters mutex in waiters recovery Alexander Aring
2024-04-02 19:18 ` [PATCHv4 dlm/next 09/15] dlm: convert ls_waiters_mutex to spinlock Alexander Aring
2024-04-02 19:18 ` [PATCHv4 dlm/next 10/15] dlm: convert res_lock " Alexander Aring
2024-04-02 19:18 ` [PATCHv4 dlm/next 11/15] dlm: make requestqueue handling non sleepable Alexander Aring
2024-04-02 19:18 ` [PATCHv4 dlm/next 12/15] dlm: ls_recv_active semaphore to rwlock Alexander Aring
2024-04-02 19:18 ` [PATCHv4 dlm/next 13/15] dlm: remove schedule in dlm receive path Alexander Aring
2024-04-02 19:18 ` [PATCHv4 dlm/next 14/15] dlm: convert message parsing locks to disable bh Alexander Aring
2024-04-02 19:18 ` Alexander Aring [this message]
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=20240402191810.1932939-16-aahringo@redhat.com \
--to=aahringo@redhat.com \
--cc=gfs2@lists.linux.dev \
--cc=teigland@redhat.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