Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sun, 20 Nov 2022 14:27:30 -0500
From:   Steven Rostedt <rostedt@goodmis.org>
To:     Xuewen Yan <xuewen.yan94@gmail.com>
Cc:     Xuewen Yan <xuewen.yan@unisoc.com>, peterz@infradead.org,
        mingo@redhat.com, juri.lelli@redhat.com,
        vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
        bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
        vschneid@redhat.com, ke.wang@unisoc.com,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched/rt: Use cpu_active_mask to prevent
 rto_push_irq_work's dead loop
Message-ID: <20221120142730.4d863176@rorschach.local.home>
In-Reply-To: <CAB8ipk8xXWzc_PurHwVPd9-azN4B5OD=MYQP+Oze1kmbom0avQ@mail.gmail.com>
References: <20221114120453.3233-1-xuewen.yan@unisoc.com>
        <20221117170028.04fd7013@gandalf.local.home>
        <CAB8ipk8xXWzc_PurHwVPd9-azN4B5OD=MYQP+Oze1kmbom0avQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Precedence: bulk

On Fri, 18 Nov 2022 20:08:54 +0800
Xuewen Yan <xuewen.yan94@gmail.com> wrote:

> Let's consider this scenario:
> the online_cpu_mask is 0x03(cpu0/1)，the active_cpu_mask is
> 0x01(cpu0)，the rto cpu is cpu0,
> the rto_mask is 0x01, and the irq cpu is cpu0, as a result,  the first
> loop, the rto_cpu would be -1,
> but the loop < rto_loop_next, on  next loop, because of the rto_cpu is
> -1, so the next rto cpu would
> be cpu0 still, as a result, the cpu0 would push rt tasks to
> cpu1(inactive cpu) while running in the irq_work.
> 
> So we should judge whether the current cpu(the only one active cpu) is
> the next loop's cpu.

Wait, I'm confused by what you are trying to do here.

The rto_next_cpu() only sends an IPI to the next CPU that has more than
one RT task queued on it, where the RT tasks can migrate.

If we send CPU0 an IPI, let CPU0 figure out to only push to the active
mask. Why are trying to prevent sending the IPI to an active CPU?

Will the first part of your patch that modifies the cpupri() not keep
it from pushing to the non active CPU?

-- Steve