From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965265AbcAUOTd (ORCPT ); Thu, 21 Jan 2016 09:19:33 -0500 Received: from mail-wm0-f51.google.com ([74.125.82.51]:36460 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759175AbcAUOTb (ORCPT ); Thu, 21 Jan 2016 09:19:31 -0500 Subject: Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings To: Thomas Gleixner 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> <56A0A9E3.2070306@linaro.org> Cc: Peter Zijlstra , 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: <56A0E8F1.7010409@linaro.org> Date: Thu, 21 Jan 2016 15:19:29 +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/21/2016 02:52 PM, Thomas Gleixner wrote: > On Thu, 21 Jan 2016, Daniel Lezcano wrote: >> On 01/20/2016 08:57 PM, Thomas Gleixner wrote: >>> 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. > > So my comment about double sampling applies. > >> 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 ? > > And why would that thing care about shared interruts at all? It's a legacy > burden and I really don't see a reason why that new thing which is targeted on > modern hardware should deal with them. Just treat them as a single interrupt > for now and be done with it. I just sent an email about how handling them :) If the shared interrupts are only related to old hardware, these ones shouldn't have cpuidle, hence there is no need to enable the irq timings. So you are right in this case and we can keep the feature simple. On a other hand, Peter sent three examples of /proc/interrupts with shared interrupts. I don't know how old are the platforms and what are they, but it seems the shared irq are still used. At this point I have two contradictory information. For the best of my knowledge, I am inclined to agree with you. Peter can you give your opinion ? -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog