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;
Date:   Tue, 23 Feb 2021 16:52:01 +0100
From:   Petr Mladek <pmladek@suse.com>
To:     Yiwei Zhang <zzyiwei@android.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>
Subject: Re: [PATCH] kthread: add kthread_mod_pending_delayed_work api
Message-ID: <YDUkoTGk2G/GZj8w@alley>
References: <20210214000611.2169820-1-zzyiwei@android.com>
 <YC+ZQAwwb4RGgjDf@alley>
 <CAKB3++YB3xftQFgSGQXKQucuid9sFywjN1E7nQ6QrqR96+heEg@mail.gmail.com>
 <CAKB3++b4wnsh+Kbgk4U200hLQmudM28sK=s9e6mARpM-eZ2ZZw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKB3++b4wnsh+Kbgk4U200hLQmudM28sK=s9e6mARpM-eZ2ZZw@mail.gmail.com>
Precedence: bulk

On Mon 2021-02-22 16:58:46, Yiwei Zhang wrote:
> Since you awesome guys are here, I do have another kthread related
> question, and hopefully to get some suggestions:
> 
> Below are the conditions:
> 1. The caller threads queuing the work are normal threads(non-RT).
> 2. The worker thread is a realtime kernel thread with relatively high prio.
> 3. We are not allowed to pin caller threads to fixed cpu clusters.
> 
> Sometimes when the CPU is busy, the worker thread starts preempting
> the caller thread,

This works as expected. RT tasks have higher priority than normal tasks.

> 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.

Best Regards,
Petr