From mboxrd@z Thu Jan 1 00:00:00 1970 From: valdis.kletnieks@vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 16 Nov 2018 13:31:51 -0500 Subject: [ARM64] Printing IRQ stack usage information In-Reply-To: References: <28496.1542300549@turing-police.cc.vt.edu> <49219.1542367988@turing-police.cc.vt.edu> <5997.1542386778@turing-police.cc.vt.edu> Message-ID: <15703.1542393111@turing-police.cc.vt.edu> To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org 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, and then you create a /proc/something or similar that when read does a 'foreach CPU do print_high_water_irq'. > 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? 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'. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omr2.cc.ipv6.vt.edu ([2607:b400:92:8400:0:33:fb76:806e] helo=omr2.cc.vt.edu) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gNiuO-0004FO-JY for kernelnewbies@kernelnewbies.org; Fri, 16 Nov 2018 13:32:00 -0500 Received: from mr3.cc.vt.edu (mr3.cc.ipv6.vt.edu [IPv6:2607:b400:92:8500:0:7f:b804:6b0a]) by omr2.cc.vt.edu (8.14.4/8.14.4) with ESMTP id wAGIVx2n030463 for ; Fri, 16 Nov 2018 13:31:59 -0500 Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by mr3.cc.vt.edu (8.14.7/8.14.7) with ESMTP id wAGIVrmG018882 for ; Fri, 16 Nov 2018 13:31:58 -0500 Received: by mail-qk1-f197.google.com with SMTP id x125so35452203qka.17 for ; Fri, 16 Nov 2018 10:31:58 -0800 (PST) From: valdis.kletnieks@vt.edu To: Pintu Agarwal Subject: Re: [ARM64] Printing IRQ stack usage information In-Reply-To: References: <28496.1542300549@turing-police.cc.vt.edu> <49219.1542367988@turing-police.cc.vt.edu> <5997.1542386778@turing-police.cc.vt.edu> Mime-Version: 1.0 Date: Fri, 16 Nov 2018 13:31:51 -0500 Message-ID: <15703.1542393111@turing-police.cc.vt.edu> Cc: mark.rutland@arm.com, Jungseok Lee , kernelnewbies@kernelnewbies.org, catalin.marinas@arm.com, Sungjinn Chung , will.deacon@arm.com, open list , Russell King - ARM Linux , Takahiro Akashi , linux-arm-kernel@lists.infradead.org List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2100184624547667683==" Errors-To: kernelnewbies-bounces@kernelnewbies.org Message-ID: <20181116183151.m00GrrFPudWbycxd_WsGW-d-6-rafhTS7_iQir35F9U@z> --===============2100184624547667683== Content-Type: multipart/signed; boundary="==_Exmh_1542393111_2640P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit --==_Exmh_1542393111_2640P Content-Type: text/plain; charset=us-ascii 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, and then you create a /proc/something or similar that when read does a 'foreach CPU do print_high_water_irq'. > 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? 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'. --==_Exmh_1542393111_2640P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Comment: Exmh version 2.9.0 11/07/2018 iQEVAwUBW+8NF40DS38y7CIcAQLYigf6AquROVf8D2XZsVziGWixUOH/mFLhro6x Ez3kExhZze5EHeWXkLumwNtbwnb8hPVaBM49eRfd9ZUnCJ9jDGaJ5pF+BghOfn92 232Lth60sLZlGiibXhiEiXX0Ok1/l5WtyzbKw8EOqcJnCPBxvCAziADeXenUciU0 UwWN/PHOnoRTHUacEXrMJUlAL9bZhJeOWukkYbmfo1ve2cHb3zWlWoUN209yZZ24 p7FGN5O3l2aJhwtmjOnd1QRb6/et1Fkbr5UEEnfsGcp28a8SFBKGwZDM39PPhB49 q4eazqIaoZrEPgDdGG8f9tgsh5wJ8mzsJXpamgRMy2Ye/DBaKCN36g== =jztX -----END PGP SIGNATURE----- --==_Exmh_1542393111_2640P-- --===============2100184624547667683== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies --===============2100184624547667683==--