From: Lyude Paul <lyude@redhat.com>
To: dri-devel@lists.freedesktop.org
Cc: Petr Mladek <pmladek@suse.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org,
"Steven Rostedt \(VMware\)" <rostedt@goodmis.org>,
Ben Dooks <ben.dooks@codethink.co.uk>, Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Suren Baghdasaryan <surenb@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Liang Chen <cl@rock-chips.com>
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
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: 43+ 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 ` Lyude Paul
2020-04-17 19:40 ` 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-17 19:40 ` Lyude Paul
2020-04-21 12:29 ` Daniel Vetter
2020-04-21 12:29 ` Daniel Vetter
2020-04-17 19:40 ` Lyude Paul [this message]
2020-04-17 19:40 ` [RFC v3 02/11] kthread: Introduce __kthread_queue_work() Lyude Paul
2020-04-17 19:40 ` [RFC v3 03/11] drm/vblank: Add vblank works Lyude Paul
2020-04-17 19:40 ` Lyude Paul
2020-04-17 20:16 ` [Poke: Tejun] " Lyude Paul
2020-04-17 20:16 ` Lyude Paul
2020-04-17 21:03 ` Tejun Heo
2020-04-17 21:03 ` Tejun Heo
2020-04-17 21:24 ` Lyude Paul
2020-04-17 21:24 ` Lyude Paul
2020-04-21 12:34 ` Daniel Vetter
2020-04-21 12:34 ` Daniel Vetter
2020-04-22 16:22 ` Tejun Heo
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 ` 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 ` 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 ` Lyude Paul
[not found] ` <20200417194145.36350-1-lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2020-04-17 19:40 ` [RFC v3 06/11] drm/nouveau/kms/nv50-: Fix disabling dithering Lyude Paul
2020-04-17 19:40 ` Lyude Paul
2020-04-17 19:40 ` 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 ` Lyude Paul
2020-04-17 19:40 ` Lyude Paul
2020-04-17 19:40 ` [RFC v3 11/11] drm/nouveau/kms/nvd9-: Add CRC support Lyude Paul
2020-04-17 19:40 ` Lyude Paul
2020-04-17 19:40 ` 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 ` 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 ` Lyude Paul
2020-04-20 23:19 ` [RFC v3 00/11] drm/nouveau: Introduce CRC support for gf119+ Ben Skeggs
2020-04-20 23:19 ` Ben Skeggs
2020-04-20 23:19 ` 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=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 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.