Date: Mon, 10 Aug 2015 18:41:34 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Juri Lelli <juri.lelli@arm.com>, LKML <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Preeti U Murthy <preeti@linux.vnet.ibm.com>,
        Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
        Viresh Kumar <viresh.kumar@linaro.org>, Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 07/10] sched: Migrate sched to use new tick dependency
 mask model
Message-ID: <20150810164134.GH16853@twins.programming.kicks-ass.net>
References: <20150803140046.GK19282@twins.programming.kicks-ass.net>
 <20150803145031.GD25554@lerouge>
 <20150803170911.GV25159@twins.programming.kicks-ass.net>
 <20150803173031.GB26022@lerouge>
 <20150804074116.GH25159@twins.programming.kicks-ass.net>
 <55C8AEDC.90603@arm.com>
 <20150810141656.GA31251@lerouge>
 <20150810142847.GE16853@twins.programming.kicks-ass.net>
 <20150810151151.GE18673@twins.programming.kicks-ass.net>
 <20150810152920.GB31251@lerouge>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150810152920.GB31251@lerouge>
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1385
Lines: 30

On Mon, Aug 10, 2015 at 05:29:22PM +0200, Frederic Weisbecker wrote:

> Well, there could be a more proper way to do this without tying that
> to the scheduler tick. This could be some sort of
> hrtimer_cancel_soft() which more generally cancels a timer without
> cancelling the interrupt itself.

So when I looked at this last -- a long long time ago -- the whole
hrtimer rbtree took a significant amount of time. Hence the proposal
here to avoid all of it for this special timer.

> We might want to still keep track of
> that lost interrupt though in case of later clock reprogramming that
> fits the lost interrupt.  With a field like
> cpu_base->expires_interrupt. I thought about expires_soft and
> expires_hard but I think that terminology is already used :-)

Its easy enough to 'fix', but typically you'd reprogram a new sched tick
anyway, so its moot. Touching the hardware twice, once to cancel the
old, once to program the new, is double pain.

The only case where you really take that interrupt is when you cancel
and go idle I suppose, and we could special case that if the NOHZ code
doesn't already DTRT (by accident) etc..

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/