From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759278AbcAUJuh (ORCPT ); Thu, 21 Jan 2016 04:50:37 -0500 Received: from mail-wm0-f41.google.com ([74.125.82.41]:37157 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759057AbcAUJua (ORCPT ); Thu, 21 Jan 2016 04:50:30 -0500 Subject: Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings To: Thomas Gleixner , Peter Zijlstra References: <1453305636-22156-1-git-send-email-daniel.lezcano@linaro.org> <1453305636-22156-2-git-send-email-daniel.lezcano@linaro.org> <20160120190718.GS6357@twins.programming.kicks-ass.net> Cc: rafael@kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, nicolas.pitre@linaro.org, vincent.guittot@linaro.org From: Daniel Lezcano Message-ID: <56A0A9E3.2070306@linaro.org> Date: Thu, 21 Jan 2016 10:50:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/20/2016 08:57 PM, Thomas Gleixner wrote: > On Wed, 20 Jan 2016, Peter Zijlstra wrote: > >> On Wed, Jan 20, 2016 at 05:00:32PM +0100, Daniel Lezcano wrote: >>> +++ b/kernel/irq/handle.c >>> @@ -165,6 +165,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc *desc) >>> /* Fall through to add to randomness */ >>> case IRQ_HANDLED: >>> flags |= action->flags; >>> + handle_irqtiming(irq, action->dev_id); >>> break; >>> >>> default: >> >>> +++ b/kernel/irq/internals.h >> >>> +static inline void handle_irqtiming(unsigned int irq, void *dev_id) >>> +{ >>> + if (__irqtimings->handler) >>> + __irqtimings->handler(irq, ktime_get(), dev_id); >>> +} >> >> Here too, ktime_get() is daft. > > What's the problem? ktime_xxx() itself or just the clock monotonic variant? > > On 99.9999% of the platforms ktime_get_mono_fast/raw_fast is not any slower > than sched_clock(). The only case where sched_clock is faster is if your TSC > is buggered and the box switches to HPET for timekeeping. > > But I wonder, whether this couldn't do with jiffies in the first place. If the > interrupt comes faster than a jiffie then you hardly go into some interesting > power state, but I might be wrong as usual :) > >> Also, you really want to take the timestamp _before_ we call the >> handlers, not after, otherwise you mix in whatever variance exist in the >> handler duration. > > That and we don't want to call it for each handler which returned handled. The > called code would do two samples in a row for the same interrupt in case of > two shared handlers which get raised at the same time. Not very likely, but > possible. Actually, the handle passes dev_id in order to let the irqtimings to sort out a shared interrupt and prevent double sampling. In other words, for shared interrupts, statistics should be per t-uple(irq , dev_id) but that is something I did not implemented ATM. IMO, the handler is at the right place. The prediction code does not take care of the shared interrupts yet. I tried to find a platform with shared interrupts in the ones I have available around me but I did not find any. Are the shared interrupts something used nowadays or coming from legacy hardware ? What is the priority to handle the shared interrupts in the prediction code ? -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog