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;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Juri Lelli <juri.lelli@redhat.com>, bigeasy@linutronix.de
Cc:     linux-rt-users@vger.kernel.org, peterz@infradead.org,
        linux-kernel@vger.kernel.org, bristot@redhat.com,
        Juri Lelli <juri.lelli@redhat.com>,
        Anna-Maria Behnsen <anna-maria@linutronix.de>
Subject: Re: [RFC PATCH RT v2 1/2] time/hrtimer: Add PINNED_HARD mode for realtime hrtimers
In-Reply-To: <87k0mqeofg.ffs@nanos.tec.linutronix.de>
References: <20210616071705.166658-1-juri.lelli@redhat.com> <20210616071705.166658-2-juri.lelli@redhat.com> <87k0mqeofg.ffs@nanos.tec.linutronix.de>
Date:   Sat, 19 Jun 2021 09:56:14 +0200
Message-ID: <87bl82e19d.ffs@nanos.tec.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On Sat, Jun 19 2021 at 01:35, Thomas Gleixner wrote:
> The wild west of anything which scratches 'my itch' based on 'my use
> case numbers' in Linux ended many years ago and while RT was always a
> valuable playground for unthinkable ideas we definitely tried hard not
> to accept use case specific hacks wihtout a proper justification that it
> makes sense in general.
>
> So why are you even trying to sell this to me?

I wouldn't have been that grumpy if you'd at least checked whether the
task is pinned. Still I would have told you that you "fix" it at the
wrong place.

Why on earth is that nohz heuristic trainwreck not even checking that?
It's not a RT problem and it's not a problem restricted to RT tasks
either. If a task is pinned then arming the timer on a random other CPU
is blatant nonsense independent of the scheduling class.

Thanks,

        tglx