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: Fri, 16 Nov 2018 11:44:36 +0530	[thread overview]
Message-ID: <CAOuPNLj8wj=tPJo8L3oS7o8iTQcyhZ0W-GH6xmP_GsG4r7YdAQ@mail.gmail.com> (raw)
In-Reply-To: <28496.1542300549@turing-police.cc.vt.edu>

On Thu, 15 Nov 2018, 10:19 pm <valdis.kletnieks@vt.edu wrote:
>
> On Thu, 15 Nov 2018 18:52:39 +0530, Pintu Agarwal said:
>
> > Currently, when I tested this (as a proc interface), I got the below output:
> > CPU    UNUSED-STACK    ACTUAL-STACK
> >  0         16368                     16384
>
> > 3) How should I test it to get the different usage values for unused stack ?
> >     Can I get these values by implementing a sample interrupt handler,
> > and printing information from there?
>
> Hint 1:  If you're in a state where seq_printf() is legal, how many IRQ's are
> on this processor's IRQ stack?
>
> Hint 2:  What are the chances that some other CPU is currently in an IRQ?
> (run 'top' and look for what percent of time that's happening)
>
> Hint 3: what are the chances that the value of irq_stack_ptr is already stale
> by the time seq_printf() finishes running?
>
> Hint 4: what happens to the validity of your output if you get rescheduled
> in the middle of that for_each loop?
>
> (In other words, this code is terribly racy and is probably not going to answer
> whatever debugging question you were working on..

Okay. Thanks so much for your hints.
Yes, I understand that this code is horribly ugly and bad.
But this is only to understand if the below logic is fine to get the
irq stack usage:
{{{
        for_each_present_cpu(cpu) {
                irq_stack_ptr = IRQ_STACK_PTR(cpu);
                //unsigned long sp = current_stack_pointer;

                stack_start = (unsigned long)per_cpu(irq_stack, cpu);
                free_stack = irq_stack_ptr - stack_start;
                seq_printf(m, "%2d %10lu %10d\n", cpu, free_stack, actual);
        }
}}}
Of course, final plan is not the proc entry, but to find a relevant
place to invoke it, probably during boot time, or during backtrace.

> If your question is "Did one
> of the CPUs blow out its IRQ stack (or come close to doing so)?" there's better
> approaches.
>
Yes, exactly, this is what the main intention.
If you have any better idea about this approach, please refer me.
It will be of great help.

Thank You!

>

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: Fri, 16 Nov 2018 11:44:36 +0530	[thread overview]
Message-ID: <CAOuPNLj8wj=tPJo8L3oS7o8iTQcyhZ0W-GH6xmP_GsG4r7YdAQ@mail.gmail.com> (raw)
In-Reply-To: <28496.1542300549@turing-police.cc.vt.edu>

On Thu, 15 Nov 2018, 10:19 pm <valdis.kletnieks@vt.edu wrote:
>
> On Thu, 15 Nov 2018 18:52:39 +0530, Pintu Agarwal said:
>
> > Currently, when I tested this (as a proc interface), I got the below output:
> > CPU    UNUSED-STACK    ACTUAL-STACK
> >  0         16368                     16384
>
> > 3) How should I test it to get the different usage values for unused stack ?
> >     Can I get these values by implementing a sample interrupt handler,
> > and printing information from there?
>
> Hint 1:  If you're in a state where seq_printf() is legal, how many IRQ's are
> on this processor's IRQ stack?
>
> Hint 2:  What are the chances that some other CPU is currently in an IRQ?
> (run 'top' and look for what percent of time that's happening)
>
> Hint 3: what are the chances that the value of irq_stack_ptr is already stale
> by the time seq_printf() finishes running?
>
> Hint 4: what happens to the validity of your output if you get rescheduled
> in the middle of that for_each loop?
>
> (In other words, this code is terribly racy and is probably not going to answer
> whatever debugging question you were working on..

Okay. Thanks so much for your hints.
Yes, I understand that this code is horribly ugly and bad.
But this is only to understand if the below logic is fine to get the
irq stack usage:
{{{
        for_each_present_cpu(cpu) {
                irq_stack_ptr = IRQ_STACK_PTR(cpu);
                //unsigned long sp = current_stack_pointer;

                stack_start = (unsigned long)per_cpu(irq_stack, cpu);
                free_stack = irq_stack_ptr - stack_start;
                seq_printf(m, "%2d %10lu %10d\n", cpu, free_stack, actual);
        }
}}}
Of course, final plan is not the proc entry, but to find a relevant
place to invoke it, probably during boot time, or during backtrace.

> If your question is "Did one
> of the CPUs blow out its IRQ stack (or come close to doing so)?" there's better
> approaches.
>
Yes, exactly, this is what the main intention.
If you have any better idea about this approach, please refer me.
It will be of great help.

Thank You!

>

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: Fri, 16 Nov 2018 11:44:36 +0530	[thread overview]
Message-ID: <CAOuPNLj8wj=tPJo8L3oS7o8iTQcyhZ0W-GH6xmP_GsG4r7YdAQ@mail.gmail.com> (raw)
In-Reply-To: <28496.1542300549@turing-police.cc.vt.edu>

On Thu, 15 Nov 2018, 10:19 pm <valdis.kletnieks@vt.edu wrote:
>
> On Thu, 15 Nov 2018 18:52:39 +0530, Pintu Agarwal said:
>
> > Currently, when I tested this (as a proc interface), I got the below output:
> > CPU    UNUSED-STACK    ACTUAL-STACK
> >  0         16368                     16384
>
> > 3) How should I test it to get the different usage values for unused stack ?
> >     Can I get these values by implementing a sample interrupt handler,
> > and printing information from there?
>
> Hint 1:  If you're in a state where seq_printf() is legal, how many IRQ's are
> on this processor's IRQ stack?
>
> Hint 2:  What are the chances that some other CPU is currently in an IRQ?
> (run 'top' and look for what percent of time that's happening)
>
> Hint 3: what are the chances that the value of irq_stack_ptr is already stale
> by the time seq_printf() finishes running?
>
> Hint 4: what happens to the validity of your output if you get rescheduled
> in the middle of that for_each loop?
>
> (In other words, this code is terribly racy and is probably not going to answer
> whatever debugging question you were working on..

Okay. Thanks so much for your hints.
Yes, I understand that this code is horribly ugly and bad.
But this is only to understand if the below logic is fine to get the
irq stack usage:
{{{
        for_each_present_cpu(cpu) {
                irq_stack_ptr = IRQ_STACK_PTR(cpu);
                //unsigned long sp = current_stack_pointer;

                stack_start = (unsigned long)per_cpu(irq_stack, cpu);
                free_stack = irq_stack_ptr - stack_start;
                seq_printf(m, "%2d %10lu %10d\n", cpu, free_stack, actual);
        }
}}}
Of course, final plan is not the proc entry, but to find a relevant
place to invoke it, probably during boot time, or during backtrace.

> If your question is "Did one
> of the CPUs blow out its IRQ stack (or come close to doing so)?" there's better
> approaches.
>
Yes, exactly, this is what the main intention.
If you have any better idea about this approach, please refer me.
It will be of great help.

Thank You!

>

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: Fri, 16 Nov 2018 11:44:36 +0530	[thread overview]
Message-ID: <CAOuPNLj8wj=tPJo8L3oS7o8iTQcyhZ0W-GH6xmP_GsG4r7YdAQ@mail.gmail.com> (raw)
Message-ID: <20181116061436.koNIPaEPXZBiOC7_qO8DTvJzaPupxe3tsPA-8vf8wCQ@z> (raw)
In-Reply-To: <28496.1542300549@turing-police.cc.vt.edu>

On Thu, 15 Nov 2018, 10:19 pm <valdis.kletnieks@vt.edu wrote:
>
> On Thu, 15 Nov 2018 18:52:39 +0530, Pintu Agarwal said:
>
> > Currently, when I tested this (as a proc interface), I got the below output:
> > CPU    UNUSED-STACK    ACTUAL-STACK
> >  0         16368                     16384
>
> > 3) How should I test it to get the different usage values for unused stack ?
> >     Can I get these values by implementing a sample interrupt handler,
> > and printing information from there?
>
> Hint 1:  If you're in a state where seq_printf() is legal, how many IRQ's are
> on this processor's IRQ stack?
>
> Hint 2:  What are the chances that some other CPU is currently in an IRQ?
> (run 'top' and look for what percent of time that's happening)
>
> Hint 3: what are the chances that the value of irq_stack_ptr is already stale
> by the time seq_printf() finishes running?
>
> Hint 4: what happens to the validity of your output if you get rescheduled
> in the middle of that for_each loop?
>
> (In other words, this code is terribly racy and is probably not going to answer
> whatever debugging question you were working on..

Okay. Thanks so much for your hints.
Yes, I understand that this code is horribly ugly and bad.
But this is only to understand if the below logic is fine to get the
irq stack usage:
{{{
        for_each_present_cpu(cpu) {
                irq_stack_ptr = IRQ_STACK_PTR(cpu);
                //unsigned long sp = current_stack_pointer;

                stack_start = (unsigned long)per_cpu(irq_stack, cpu);
                free_stack = irq_stack_ptr - stack_start;
                seq_printf(m, "%2d %10lu %10d\n", cpu, free_stack, actual);
        }
}}}
Of course, final plan is not the proc entry, but to find a relevant
place to invoke it, probably during boot time, or during backtrace.

> If your question is "Did one
> of the CPUs blow out its IRQ stack (or come close to doing so)?" there's better
> approaches.
>
Yes, exactly, this is what the main intention.
If you have any better idea about this approach, please refer me.
It will be of great help.

Thank You!

>

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

  reply	other threads:[~2018-11-16  6:14 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 [this message]
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
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='CAOuPNLj8wj=tPJo8L3oS7o8iTQcyhZ0W-GH6xmP_GsG4r7YdAQ@mail.gmail.com' \
    --to=pintu.ping@gmail.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --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=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.