lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAKB3++YFqao5f4oZ2eX3GhLDChNx5EheXG-y9aUsReY3JETYtQ@mail.gmail.com> Date: Thu, 25 Feb 2021 14:17:04 -0800 From: Yiwei Zhangā€ˇ <zzyiwei@...roid.com> To: Petr Mladek <pmladek@...e.com> Cc: Christoph Hellwig <hch@...radead.org>, Andrew Morton <akpm@...ux-foundation.org>, Felix Kuehling <Felix.Kuehling@....com>, Jens Axboe <axboe@...nel.dk>, "J. Bruce Fields" <bfields@...hat.com>, Peter Zijlstra <peterz@...radead.org>, Frederic Weisbecker <frederic@...nel.org>, Marcelo Tosatti <mtosatti@...hat.com>, Ilias Stamatis <stamatis.iliass@...il.com>, Rob Clark <robdclark@...omium.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Liang Chen <cl@...k-chips.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, kernel-team <kernel-team@...roid.com> Subject: Re: [PATCH] kthread: add kthread_mod_pending_delayed_work api On Wed, Feb 24, 2021 at 1:34 AM Petr Mladek <pmladek@...e.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.
Powered by blists - more mailing lists