Messages in this thread | | | From | Yiwei Zhang <> | Date | Thu, 25 Feb 2021 14:17:04 -0800 | Subject | Re: [PATCH] kthread: add kthread_mod_pending_delayed_work api |
| |
On Wed, Feb 24, 2021 at 1:34 AM Petr Mladek <pmladek@suse.com> wrote: > > On Tue 2021-02-23 14:29:37, Yiwei Zhang wrote: > > > > which is not cool because it will make the > > > > asynchronous effort a no-op. Is there a way we can include caller > > > > thread metadata(task_struct pointer?) when it enqueues the work so > > > > that the RT worker thread won't preempt the caller thread when that > > > > queued work gets scheduled? Probably require the CPU scheduler to poke > > > > at the next work...or any other ideas will be very appreciated, > > > > thanks! > > > > > > This sounds like a very strange use case. > > > Why is the worker kthread RT when the work can be delayed? > > > > > > If the kthread has to be RT because of another work then > > > your proposal will not work. The delayed processing of > > > low priority work might block and delay any pending > > > high priority work. > > > > > > You should consider handling the less important work in a separate > > > kthread worker with a lower priority or by the system workqueue. > > > > Just want to clarify that it's not about delayed_work any more. In my > > latest question, it's a RT thread with normal work queued and > > scheduled to be run immediately. However, I simply don't want the > > worker to preempt the thread that queues the work. > > > > It's a high prio work that we don't want other random tasks to preempt > > it. Meanwhile, we don't want it to preempt the called thread. In > > addition, assume we can't raise the priority of those caller > > threads(otherwise I'd be fine with using a workqueue). > > Honestly, it sounds weird to me. Either the caller or the > worker has higher priority. > > Well, I think that behavior could be achieved by > CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY. > > Anyway, this is rather a question for scheduler experts. > It is possible that it has some solution. But it is also > possible that it is so specific behavior and it would > complicate the scheduler too much. > > Best Regards, > Petr
Thanks for the pointers! I'll explore further with scheduling folks.
| |