From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751616AbcFWKO4 (ORCPT ); Thu, 23 Jun 2016 06:14:56 -0400 Received: from www.linutronix.de ([62.245.132.108]:47046 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751089AbcFWKOy (ORCPT ); Thu, 23 Jun 2016 06:14:54 -0400 Date: Thu, 23 Jun 2016 12:12:51 +0200 (CEST) From: Thomas Gleixner To: Daniel Lezcano cc: nicolas.pitre@linaro.org, shreyas@linux.vnet.ibm.com, linux-kernel@vger.kernel.org, peterz@infradead.org, rafael@kernel.org, vincent.guittot@linaro.org Subject: Re: [PATCH V7] irq: Track the interrupt timings In-Reply-To: <576BAE3F.5030603@linaro.org> Message-ID: References: <1466183776-5296-1-git-send-email-daniel.lezcano@linaro.org> <576BAE3F.5030603@linaro.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 23 Jun 2016, Daniel Lezcano wrote: > On 06/23/2016 10:41 AM, Thomas Gleixner wrote: > > Is it really required to do this per interrupt rather than providing per cpu > > statistics of interrupts which arrived in the last X seconds or whatever > > timeframe is relevant for this. > > Perhaps I am misunderstanding but if the statistics are done per cpu without > tracking per irq timings, it is not possible to extract a repeating pattern > for each irq and have an accurate prediction. I don't see why you need a repeating pattern for each irq. All you want to know is whether there are repeating patterns of interrupts on a particular cpu. struct per_cpu_stat { u32 irq; u64 ts; }; storing 32 entries of the above should give you enough information about patterns etc. If you have a high rate of interrupts on that cpu it does not matter at all whether thats from one or several devices. If you have only a few then this storage is sufficient to get the desired information. > If we step back and look at the potential users of this framework, we have: > > - mobile: by nature the interrupt line number is small and the devices are > "slow" > > - desktop and laptop : a few interrupts are really interesting us, ethernet > and sdd (the other ones are rare, or ignored like timers or IPI) You still walk ALL interrupts. On my laptop that's 22 of them. And you touch every single per cpu storage of each interrupt. > - server : the interrupt line number is bigger, but not so much. Not so much? 158 interrupts on one of my larger machines. > Usually, server and super sized system want full performance and low latency. > For this reason the kernel is configured with periodic tick and that makes the > next prediction algorithm superfluous, especially when the latency is set to > 0. So I don't think the irq timings + next irq event code path will be ever > used in this case. Well, if such a machine runs with NOHZ=n then fine. But there are enough machines where NOHZ is enabled so you get better power savings during times where the machine is not loaded, but you want to have performance and low latency if there is work to do. > As you mentioned it, there are some parts we can make evolve and optimize like > preventing to lookup an empty irq events cpu. You better think about this now. Thanks, tglx