Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp550864imu; Sat, 17 Nov 2018 05:07:57 -0800 (PST) X-Google-Smtp-Source: AJdET5d2Zm5fnA+wEuLNFmDgKSHvIkobR1jgV3Sh1n2EMkl/drp3QYPRxYYj7v99ahPkVpmnFUR8 X-Received: by 2002:a63:7d06:: with SMTP id y6mr13505070pgc.171.1542460077257; Sat, 17 Nov 2018 05:07:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542460077; cv=none; d=google.com; s=arc-20160816; b=c6S9leexDd8FQ8D5E1V+Dcz9YqHRGlJ2gJE12EU1Mq2q+xenAVLqhR0v2tXG/uQEvB NiS6KClJ1KmoZPVYd10g0YfPVzUDqfAkjWyED3y62P17urbuN1DNmd5mtuNXxtcubNSh 1/X8Qn3iZ7WWU9whtz5OWaS2uId9G580jN4iLF1I5LUTDdV4lAfF/XwtLbH85nmci+u3 bbY7kIbUifvgO9lyRAw7X+IiQzwUQiCW78FaijeEJwRCBwCbnEhZ9vJADBAjzz26QhH9 CRy8kXMMCF3OFfIj/42yFzPGLzUNtHBt9mTxrjM1/fPegQo1JLQwrSPUZJvy3tnwYQB0 IuZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=ATNYsZQD9kqFrtWh2QrnOAbT12lJv2SDV+L9L+hhtQc=; b=dmBTtfUz3HpneCwaUXOXQgoTRqJmiHRd3IUDpCj/Et33bL0g7D7zUhLJK/vK830ABh OFgDCh5LiUD4bsiktC5v/z1zNKhwKqWMBaa26HLEH6FdJmO/rj1iscT0IneqUkOjbd2N iJ3lv1HwxR8BRCgr1CzQ7m8R8N/nW91SBmbftINxwegcYif/9RUBGIDWf0Xhady6q9r1 +WXv30mxPbuySQyRVLx+8qzKtKkRDAWKw8PwcHk6saZZFIl2uQyYkNSjy6RY7kNcUJkk 1T5DZTaMdIJcZHHlqoYe/AO4HopeMBsR1tQIuEq0yxscj3z7vLJBhM1DqBxvhd9QyNj8 mZgQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ZgP25Hxo; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y1si33369581pgy.174.2018.11.17.05.07.26; Sat, 17 Nov 2018 05:07:57 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ZgP25Hxo; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726414AbeKQXXD (ORCPT + 99 others); Sat, 17 Nov 2018 18:23:03 -0500 Received: from mail-vs1-f67.google.com ([209.85.217.67]:36625 "EHLO mail-vs1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726020AbeKQXXD (ORCPT ); Sat, 17 Nov 2018 18:23:03 -0500 Received: by mail-vs1-f67.google.com with SMTP id v205so15328151vsc.3 for ; Sat, 17 Nov 2018 05:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ATNYsZQD9kqFrtWh2QrnOAbT12lJv2SDV+L9L+hhtQc=; b=ZgP25HxouxcGTqR7fmuyzHOcFg2a6Gtc9rKQFwcTkg9iMGlf7cX4vGyjto+P2HKWrO qQA79g4vyfT6hDTAjxeOCm1Q24Rlmu83sLuCzNts59WUIU0hH4WxG1K2lCIETYeXGhz5 dNGMR6RCCcKS6Z8FO5XVZGB8pd8rrjUJ7q08nrwC8Ad3RBRGwHhobKHRJ84nPMgIufII Ia66Kx+aQHkIMmwuq68OD/0VQPIT+tiakFdstnqRHmGFrNLMtzFWukLSzHg3w6MllSpF mBTTE4L+k1z+dRFypL7/7tMgQ05s+49np87qy8B8kHmEmwmhmIYGdPk5bsUjLPNmyc+p HOog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ATNYsZQD9kqFrtWh2QrnOAbT12lJv2SDV+L9L+hhtQc=; b=XfMITd9nQRWY5F6kDNjo5/D9ir6t7PTK00CIi7PhDDMx3UG/Qf8+CnnF0XyxcU/ZSu 50yEiqxzrMblmxxN9yIW6LjJmCsEvlVfy3f8d0KUkpBpFtFOMeSDwMZKTZH3DwnvOhtY ODmQ3cTvE9HjGrGp0SdDE8W7eX3YPzuiqD3c/lvLapZQsoei4tT/ogeDUDvCJgLFScd3 O1s9c3cTKs2UB2yzvTqWT3BcVeY2/6kWZ0GGjQhBtMKClZHSd18rqKW/WUIVPQk+DV4P sg0n3gJSuyucImV/g/CdGan8afFSD+xYZFPzPNexCGLoHLzWqOMnFE/UGuu8XKHlhEE2 mS9w== X-Gm-Message-State: AGRZ1gJLVuo+vh/DgY9wNlU0JouTelMrfVkwhEMWCZqP6CTJ12xPXVEU 02jj3WzDRLPhHutE1u02KI3Z+zwZWYwLZ9ipKXqVICVn X-Received: by 2002:a67:f756:: with SMTP id w22mr6276718vso.30.1542459984106; Sat, 17 Nov 2018 05:06:24 -0800 (PST) MIME-Version: 1.0 References: <28496.1542300549@turing-police.cc.vt.edu> <49219.1542367988@turing-police.cc.vt.edu> <5997.1542386778@turing-police.cc.vt.edu> <15703.1542393111@turing-police.cc.vt.edu> In-Reply-To: <15703.1542393111@turing-police.cc.vt.edu> From: Pintu Agarwal Date: Sat, 17 Nov 2018 18:36:12 +0530 Message-ID: Subject: Re: [ARM64] Printing IRQ stack usage information To: Valdis Kletnieks Cc: open list , linux-arm-kernel@lists.infradead.org, Russell King - ARM Linux , kernelnewbies@kernelnewbies.org, Jungseok Lee , catalin.marinas@arm.com, will.deacon@arm.com, Takahiro Akashi , mark.rutland@arm.com, Sungjinn Chung Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 17, 2018 at 12:02 AM wrote: > > On Fri, 16 Nov 2018 23:13:48 +0530, Pintu Agarwal said: > > On Fri, Nov 16, 2018 at 10:16 PM wrote: > > > > Congrats. You just re-invented DEBUG_STACK_USAGE, which just keeps a high-water mark > > > for stack usage. > > > > So, you mean to say, my implementation is good enough to get the > > irq_stack usage, from the interrupt handler ? > > No - your code doesn't keep a high-water mark (which should probably be > hooked into the IRQ exit code. > > > But my concern is that if I dump it from irq handler, I will get > > information only for the current cpu. > > How do I store and get the information for all the cpu from the boot time ? > > Make the high-water mark a per-cpu variable. > > > From where do I call my dump_irq_stack_info() [some where during the > > entry/exit part of the irq handler], so that I could dump information > > for all the handler at boot time itself ? > > No, you don't do a dump-stack during entry/exit. You just maintain a high-water > value in the exit, Which is the right place to keep track of this high-water-irq-stack-usage (per_cpu) in arch/arm64/* ? > and then you create a /proc/something or similar that when > read does a 'foreach CPU do print_high_water_irq'. > Ok got it. > > Like I would to capture these information: > > - What was the name of the handler ? > > - Which cpu was executing it ? > > - How much irq stack (max value, same like high water mark) were used > > at that time ? > > First, do the easy part and find out if you even *care* once you see actual > numbers. If your IRQ stack is 8K but you never use more than 2500 bytes, > do you *really* care about the name of the handler anymore? > Hmm, yes, getting the name of the handler is not so important in the first run. > Also, see the code for /proc/interrupts to see how it keeps track of the > interrupts per CPU - maybe all you need to do is change each entry from > a 'count' to 'count, highwater'. Ok thanks, thats a good pointer.