All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pintu Agarwal <pintu.ping@gmail.com>
To: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Cc: open list <linux-kernel@vger.kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	kernelnewbies@kernelnewbies.org,
	Jungseok Lee <jungseoklee85@gmail.com>,
	catalin.marinas@arm.com, will.deacon@arm.com,
	Takahiro Akashi <takahiro.akashi@linaro.org>,
	mark.rutland@arm.com, Sungjinn Chung <barami97@gmail.com>
Subject: Re: [ARM64] Printing IRQ stack usage information
Date: Sat, 17 Nov 2018 18:36:12 +0530	[thread overview]
Message-ID: <CAOuPNLiJmtXft6g63oATMrrrcd3jQGCfxsAzXLx8Kz=_zsR4Kg@mail.gmail.com> (raw)
In-Reply-To: <15703.1542393111@turing-police.cc.vt.edu>

On Sat, Nov 17, 2018 at 12:02 AM <valdis.kletnieks@vt.edu> wrote:
>
> On Fri, 16 Nov 2018 23:13:48 +0530, Pintu Agarwal said:
> > On Fri, Nov 16, 2018 at 10:16 PM <valdis.kletnieks@vt.edu> 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.

WARNING: multiple messages have this Message-ID (diff)
From: pintu.ping@gmail.com (Pintu Agarwal)
To: linux-arm-kernel@lists.infradead.org
Subject: [ARM64] Printing IRQ stack usage information
Date: Sat, 17 Nov 2018 18:36:12 +0530	[thread overview]
Message-ID: <CAOuPNLiJmtXft6g63oATMrrrcd3jQGCfxsAzXLx8Kz=_zsR4Kg@mail.gmail.com> (raw)
In-Reply-To: <15703.1542393111@turing-police.cc.vt.edu>

On Sat, Nov 17, 2018 at 12:02 AM <valdis.kletnieks@vt.edu> wrote:
>
> On Fri, 16 Nov 2018 23:13:48 +0530, Pintu Agarwal said:
> > On Fri, Nov 16, 2018 at 10:16 PM <valdis.kletnieks@vt.edu> 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.

WARNING: multiple messages have this Message-ID (diff)
From: pintu.ping@gmail.com (Pintu Agarwal)
To: kernelnewbies@lists.kernelnewbies.org
Subject: [ARM64] Printing IRQ stack usage information
Date: Sat, 17 Nov 2018 18:36:12 +0530	[thread overview]
Message-ID: <CAOuPNLiJmtXft6g63oATMrrrcd3jQGCfxsAzXLx8Kz=_zsR4Kg@mail.gmail.com> (raw)
In-Reply-To: <15703.1542393111@turing-police.cc.vt.edu>

On Sat, Nov 17, 2018 at 12:02 AM <valdis.kletnieks@vt.edu> wrote:
>
> On Fri, 16 Nov 2018 23:13:48 +0530, Pintu Agarwal said:
> > On Fri, Nov 16, 2018 at 10:16 PM <valdis.kletnieks@vt.edu> 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.

WARNING: multiple messages have this Message-ID (diff)
From: Pintu Agarwal <pintu.ping@gmail.com>
To: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Cc: mark.rutland@arm.com, Jungseok Lee <jungseoklee85@gmail.com>,
	kernelnewbies@kernelnewbies.org, catalin.marinas@arm.com,
	Sungjinn Chung <barami97@gmail.com>,
	will.deacon@arm.com, open list <linux-kernel@vger.kernel.org>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	Takahiro Akashi <takahiro.akashi@linaro.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [ARM64] Printing IRQ stack usage information
Date: Sat, 17 Nov 2018 18:36:12 +0530	[thread overview]
Message-ID: <CAOuPNLiJmtXft6g63oATMrrrcd3jQGCfxsAzXLx8Kz=_zsR4Kg@mail.gmail.com> (raw)
Message-ID: <20181117130612.YSiVn8UVxZ0yS_uVx5iSmGQmBZ-cjTU51zmuNNOZAtk@z> (raw)
In-Reply-To: <15703.1542393111@turing-police.cc.vt.edu>

On Sat, Nov 17, 2018 at 12:02 AM <valdis.kletnieks@vt.edu> wrote:
>
> On Fri, 16 Nov 2018 23:13:48 +0530, Pintu Agarwal said:
> > On Fri, Nov 16, 2018 at 10:16 PM <valdis.kletnieks@vt.edu> 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.

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

  reply	other threads:[~2018-11-17 13:06 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-15 13:22 [ARM64] Printing IRQ stack usage information Pintu Agarwal
2018-11-15 13:22 ` Pintu Agarwal
2018-11-15 13:22 ` Pintu Agarwal
2018-11-15 13:22 ` Pintu Agarwal
2018-11-15 16:49 ` valdis.kletnieks
2018-11-15 16:49   ` valdis.kletnieks
2018-11-15 16:49   ` valdis.kletnieks at vt.edu
2018-11-15 16:49   ` valdis.kletnieks at vt.edu
2018-11-16  6:14   ` Pintu Agarwal
2018-11-16  6:14     ` Pintu Agarwal
2018-11-16  6:14     ` Pintu Agarwal
2018-11-16  6:14     ` Pintu Agarwal
2018-11-16 11:33     ` valdis.kletnieks
2018-11-16 11:33       ` valdis.kletnieks
2018-11-16 11:33       ` valdis.kletnieks at vt.edu
2018-11-16 11:33       ` valdis.kletnieks at vt.edu
2018-11-16 14:40       ` Pintu Agarwal
2018-11-16 14:40         ` Pintu Agarwal
2018-11-16 14:40         ` Pintu Agarwal
2018-11-16 14:40         ` Pintu Agarwal
2018-11-16 16:46         ` valdis.kletnieks
2018-11-16 16:46           ` valdis.kletnieks
2018-11-16 16:46           ` valdis.kletnieks at vt.edu
2018-11-16 16:46           ` valdis.kletnieks at vt.edu
2018-11-16 17:43           ` Pintu Agarwal
2018-11-16 17:43             ` Pintu Agarwal
2018-11-16 17:43             ` Pintu Agarwal
2018-11-16 17:43             ` Pintu Agarwal
2018-11-16 18:31             ` valdis.kletnieks
2018-11-16 18:31               ` valdis.kletnieks
2018-11-16 18:31               ` valdis.kletnieks at vt.edu
2018-11-16 18:31               ` valdis.kletnieks at vt.edu
2018-11-17 13:06               ` Pintu Agarwal [this message]
2018-11-17 13:06                 ` Pintu Agarwal
2018-11-17 13:06                 ` Pintu Agarwal
2018-11-17 13:06                 ` Pintu Agarwal
2018-11-20 12:51                 ` Pintu Agarwal
2018-11-20 12:51                   ` Pintu Agarwal
2018-11-20 12:51                   ` Pintu Agarwal
2018-11-20 12:51                   ` Pintu Agarwal
2018-11-20 19:03                   ` valdis.kletnieks
2018-11-20 19:03                     ` valdis.kletnieks
2018-11-20 19:03                     ` valdis.kletnieks at vt.edu
2018-11-20 19:03                     ` valdis.kletnieks at vt.edu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOuPNLiJmtXft6g63oATMrrrcd3jQGCfxsAzXLx8Kz=_zsR4Kg@mail.gmail.com' \
    --to=pintu.ping@gmail.com \
    --cc=barami97@gmail.com \
    --cc=catalin.marinas@arm.com \
    --cc=jungseoklee85@gmail.com \
    --cc=kernelnewbies@kernelnewbies.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=takahiro.akashi@linaro.org \
    --cc=valdis.kletnieks@vt.edu \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.