linux-kernel - Re: [PATCH] kthread: add kthread_mod_pending_delayed

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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.