Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210214000611.2169820-1-zzyiwei@android.com> <YC+ZQAwwb4RGgjDf@alley>
 <CAKB3++YB3xftQFgSGQXKQucuid9sFywjN1E7nQ6QrqR96+heEg@mail.gmail.com>
 <CAKB3++b4wnsh+Kbgk4U200hLQmudM28sK=s9e6mARpM-eZ2ZZw@mail.gmail.com>
 <YDUkoTGk2G/GZj8w@alley> <CAKB3++Yf5cv8shHU0T1nqfNTgbknU1uMu54YXWqNGqXHpa_oAA@mail.gmail.com>
 <YDYdoRwezfVsWS4W@alley>
In-Reply-To: <YDYdoRwezfVsWS4W@alley>
From:   =?UTF-8?B?WWl3ZWkgWmhhbmfigI4=?= <zzyiwei@android.com>
Date:   Thu, 25 Feb 2021 14:17:04 -0800
Message-ID: <CAKB3++YFqao5f4oZ2eX3GhLDChNx5EheXG-y9aUsReY3JETYtQ@mail.gmail.com>
Subject: Re: [PATCH] kthread: add kthread_mod_pending_delayed_work api
To:     Petr Mladek <pmladek@suse.com>
Cc:     Christoph Hellwig <hch@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Felix Kuehling <Felix.Kuehling@amd.com>,
        Jens Axboe <axboe@kernel.dk>,
        "J. Bruce Fields" <bfields@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Frederic Weisbecker <frederic@kernel.org>,
        Marcelo Tosatti <mtosatti@redhat.com>,
        Ilias Stamatis <stamatis.iliass@gmail.com>,
        Rob Clark <robdclark@chromium.org>,
        Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
        Liang Chen <cl@rock-chips.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        kernel-team <kernel-team@android.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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.