From: Lyude Paul <lyude@redhat.com>
To: dri-devel@lists.freedesktop.org
Cc: Daniel Vetter <daniel@ffwll.ch>, Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Petr Mladek <pmladek@suse.com>,
Suren Baghdasaryan <surenb@google.com>,
"Steven Rostedt (VMware)" <rostedt@goodmis.org>,
Ben Dooks <ben.dooks@codethink.co.uk>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Liang Chen <cl@rock-chips.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org
Subject: [RFC v3 02/11] kthread: Introduce __kthread_queue_work()
Date: Fri, 17 Apr 2020 15:40:49 -0400 [thread overview]
Message-ID: <20200417194145.36350-3-lyude@redhat.com> (raw)
In-Reply-To: <20200417194145.36350-1-lyude@redhat.com>
While kthread_queue_work() is fine for basic kthread_worker usecases,
it's a little limiting if you want to create your own delayed work
implementations that delay off things other than a clock. Looking at
kthread_delayed_works for instance, all of the code shares the lock in
kthread_work so that that both the timer_list and actual kthread_worker
can be inspected and modified together atomically.
Currently, we want to be able to implement a type of delayed
kthread_work in DRM that delays until a specific vblank sequence has
passed, which we refer to as a drm_vblank_work, as opposed to using a
simple time-based delay. Some of the requirements we have for this are
the ability to allow for rescheduling and flushing on drm_vblank_works,
which become a lot harder to do properly if we can't re-queue work under
lock. Additionally, being able to specify a custom position in the
kthread_worker's work_list (which requires being under lock) is
important to be able to do since it's needed for implementing a custom
work flushing mechanism that waits for both the vblank sequence and
kthread_worker to complete once.
So - let's expose an unlocked version of kthread_queue_work() called
__kthread_queue_work(), which also allows for specifying a custom list
position in which to insert the work before.
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Lyude Paul <lyude@redhat.com>
---
include/linux/kthread.h | 3 +++
kernel/kthread.c | 34 ++++++++++++++++++++++++++++++----
2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index 8bbcaad7ef0f..02e0c1c157bf 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -179,6 +179,9 @@ __printf(3, 4) struct kthread_worker *
kthread_create_worker_on_cpu(int cpu, unsigned int flags,
const char namefmt[], ...);
+bool __kthread_queue_work(struct kthread_worker *worker,
+ struct kthread_work *work,
+ struct list_head *pos);
bool kthread_queue_work(struct kthread_worker *worker,
struct kthread_work *work);
diff --git a/kernel/kthread.c b/kernel/kthread.c
index bfbfa481be3a..46de56142593 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -816,6 +816,35 @@ static void kthread_insert_work(struct kthread_worker *worker,
wake_up_process(worker->task);
}
+/**
+ * __kthread_queue_work - queue a kthread_work while under lock
+ * @worker: target kthread_worker
+ * @work: kthread_work to queue
+ * @pos: The position in @worker.work_list to insert @work before
+ *
+ * This is the same as kthread_queue_work(), except that it already expects
+ * the caller to be holding &kthread_worker.lock and allows for specifying a
+ * custom position in @worker.work_list to insert @work before.
+ *
+ * This function is mostly useful for users which might need to create their
+ * own delayed kthread_worker implementations.
+ *
+ * Returns: %true if @work was successfully queued, %false if it was already
+ * pending.
+ */
+bool __kthread_queue_work(struct kthread_worker *worker,
+ struct kthread_work *work,
+ struct list_head *pos)
+{
+ if (!queuing_blocked(worker, work)) {
+ kthread_insert_work(worker, work, pos);
+ return true;
+ }
+
+ return false;
+}
+EXPORT_SYMBOL_GPL(__kthread_queue_work);
+
/**
* kthread_queue_work - queue a kthread_work
* @worker: target kthread_worker
@@ -835,10 +864,7 @@ bool kthread_queue_work(struct kthread_worker *worker,
unsigned long flags;
raw_spin_lock_irqsave(&worker->lock, flags);
- if (!queuing_blocked(worker, work)) {
- kthread_insert_work(worker, work, &worker->work_list);
- ret = true;
- }
+ ret = __kthread_queue_work(worker, work, &worker->work_list);
raw_spin_unlock_irqrestore(&worker->lock, flags);
return ret;
}
--
2.25.1
next prev parent reply other threads:[~2020-04-17 19:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-17 19:40 [RFC v3 00/11] drm/nouveau: Introduce CRC support for gf119+ Lyude Paul
2020-04-17 19:40 ` [RFC v3 01/11] drm/vblank: Register drmm cleanup action once per drm_vblank_crtc Lyude Paul
2020-04-21 12:29 ` Daniel Vetter
2020-04-17 19:40 ` Lyude Paul [this message]
2020-04-17 19:40 ` [RFC v3 03/11] drm/vblank: Add vblank works Lyude Paul
2020-04-17 20:16 ` [Poke: Tejun] " Lyude Paul
2020-04-17 21:03 ` Tejun Heo
2020-04-17 21:24 ` Lyude Paul
2020-04-21 12:34 ` Daniel Vetter
2020-04-22 16:22 ` Tejun Heo
2020-04-17 19:40 ` [RFC v3 04/11] drm/nouveau/kms/nv50-: Unroll error cleanup in nv50_head_create() Lyude Paul
2020-04-17 19:40 ` [RFC v3 05/11] drm/nouveau/kms/nv140-: Don't modify depth in state during atomic commit Lyude Paul
2020-04-17 19:40 ` [RFC v3 06/11] drm/nouveau/kms/nv50-: Fix disabling dithering Lyude Paul
2020-04-17 19:40 ` [RFC v3 07/11] drm/nouveau/kms/nv50-: s/harm/armh/g Lyude Paul
2020-04-17 19:40 ` [RFC v3 08/11] drm/nouveau/kms/nv140-: Track wndw mappings in nv50_head_atom Lyude Paul
2020-04-17 19:40 ` [RFC v3 09/11] drm/nouveau/kms/nv50-: Expose nv50_outp_atom in disp.h Lyude Paul
2020-04-17 19:40 ` [RFC v3 10/11] drm/nouveau/kms/nv50-: Move hard-coded object handles into header Lyude Paul
2020-04-17 19:40 ` [RFC v3 11/11] drm/nouveau/kms/nvd9-: Add CRC support Lyude Paul
2020-04-20 23:19 ` [RFC v3 00/11] drm/nouveau: Introduce CRC support for gf119+ Ben Skeggs
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=20200417194145.36350-3-lyude@redhat.com \
--to=lyude@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ben.dooks@codethink.co.uk \
--cc=cl@rock-chips.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=surenb@google.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
/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