Hi, I would like to somehow obtain local CPU core ID in the interrupt handler function. I want to see how my interruptions are distributed among different CPU cores under different conditions. How should I do that?
On March 8, 2015 3:06:23 PM EDT, "Matwey V. Kornilov" <matwey.kornilov@gmail.com> wrote:
Hi,
I would like to somehow obtain local CPU core ID in the interrupt handler function. I want to see how my interruptions are distributed among different CPU cores under different conditions.
How should I do that?
I didn't remember off hand but looked into the scheduler code where this is common. When I looked there the marco, smp_professor_id in the file include/linux/smp. h seems to be the best way to handle your task. The only concern and I am pretty certain it is, is if this marco is able to work in interrupt context a.k.a it is guaranteed to never sleep. You can either test this out and see if the system hangs or do more research into what functions and marcos work interrupt context. Hope this helps, Nick
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Sun, Mar 08, 2015 at 10:06:23PM +0300, Matwey V. Kornilov wrote:
Hi,
I would like to somehow obtain local CPU core ID in the interrupt handler function. I want to see how my interruptions are distributed among different CPU cores under different conditions.
How should I do that?
To answer strictly your question, like Nick said, smp_processor_id() will work fine. However, you can do exactly what you want be reading /proc/interrupts, that already provide the informations you are looking for. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
On March 8, 2015 5:49:00 PM EDT, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
On Sun, Mar 08, 2015 at 10:06:23PM +0300, Matwey V. Kornilov wrote:
Hi,
I would like to somehow obtain local CPU core ID in the interrupt handler function. I want to see how my interruptions are distributed among different CPU cores under different conditions.
How should I do that?
To answer strictly your question, like Nick said, smp_processor_id() will work fine.
However, you can do exactly what you want be reading /proc/interrupts, that already provide the informations you are looking for.
Maxime Good point, I totally forgot about that file in the proc directory. ☺ That was my fault. Nick
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Sun, 08 Mar 2015 22:49:00 +0100, Maxime Ripard said:
On Sun, Mar 08, 2015 at 10:06:23PM +0300, Matwey V. Kornilov wrote:
I would like to somehow obtain local CPU core ID in the interrupt handler function. I want to see how my interruptions are distributed among different CPU cores under different conditions.
How should I do that?
To answer strictly your question, like Nick said, smp_processor_id() will work fine.
However, you can do exactly what you want be reading /proc/interrupts, that already provide the informations you are looking for.
Clarification: /proc/interrupts will give userspace that information. It is *not* recommended you try to read it from kernel space, much less from an interrupt context... :)
On March 8, 2015 6:30:47 PM EDT, Valdis.Kletnieks@vt.edu wrote:
On Sun, 08 Mar 2015 22:49:00 +0100, Maxime Ripard said:
On Sun, Mar 08, 2015 at 10:06:23PM +0300, Matwey V. Kornilov wrote:
I would like to somehow obtain local CPU core ID in the interrupt handler function. I want to see how my interruptions are distributed among different CPU cores under different conditions.
How should I do that?
To answer strictly your question, like Nick said, smp_processor_id() will work fine.
However, you can do exactly what you want be reading /proc/interrupts, that already provide the informations you are looking for.
Clarification: /proc/interrupts will give userspace that information. It is *not* recommended you try to read it from kernel space, much less from an interrupt context... :)
Does that matter through as all Matwey is interested in getting are the load balancing among multiple cores on a smp based system under various workloads . I wouldn't mind recommending to just read proc/interrupts expect for it only being refreshed every 3 seconds to my knowledge by default and therefore not valid for getting per second data. Also this file doesn't explain the kernel's decision to put what work on which core on a smp capable system during interrupt context , which may also interest Matwey too. Just my opinion, Nick
------------------------------------------------------------------------
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Sun, Mar 08, 2015 at 07:10:09PM -0400, Nicholas Krause wrote:
On March 8, 2015 6:30:47 PM EDT, Valdis.Kletnieks@vt.edu wrote:
On Sun, 08 Mar 2015 22:49:00 +0100, Maxime Ripard said:
On Sun, Mar 08, 2015 at 10:06:23PM +0300, Matwey V. Kornilov wrote:
I would like to somehow obtain local CPU core ID in the interrupt handler function. I want to see how my interruptions are distributed among different CPU cores under different conditions.
How should I do that?
To answer strictly your question, like Nick said, smp_processor_id() will work fine.
However, you can do exactly what you want be reading /proc/interrupts, that already provide the informations you are looking for.
Clarification: /proc/interrupts will give userspace that information. It is *not* recommended you try to read it from kernel space, much less from an interrupt context... :)
Does that matter through as all Matwey is interested in getting are the load balancing among multiple cores on a smp based system under various workloads . I wouldn't mind recommending to just read proc/interrupts expect for it only being refreshed every 3 seconds to my knowledge by default and therefore not valid for getting per second data. Also this file doesn't explain the kernel's decision to put what work on which core on a smp capable system during interrupt context , which may also interest Matwey too.
The kernel decision is: - For SPIs, the default affinity is always on CPU0. That can be changed if someone calls irq_set_affinity. - For PPIs, the interrupt will be triggered on a particular processor, without any intervention of the kernel. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
On Sun, Mar 08, 2015 at 06:30:47PM -0400, Valdis.Kletnieks@vt.edu wrote:
On Sun, 08 Mar 2015 22:49:00 +0100, Maxime Ripard said:
On Sun, Mar 08, 2015 at 10:06:23PM +0300, Matwey V. Kornilov wrote:
I would like to somehow obtain local CPU core ID in the interrupt handler function. I want to see how my interruptions are distributed among different CPU cores under different conditions.
How should I do that?
To answer strictly your question, like Nick said, smp_processor_id() will work fine.
However, you can do exactly what you want be reading /proc/interrupts, that already provide the informations you are looking for.
Clarification: /proc/interrupts will give userspace that information. It is *not* recommended you try to read it from kernel space, much less from an interrupt context... :)
Hmmm, yes, it was a little too obvious in my mind :) Thanks for the clarification! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
You can use ftrace and such.
On Mar 8, 2015, at 12:06 PM, Matwey V. Kornilov <matwey.kornilov@gmail.com> wrote:
Hi,
I would like to somehow obtain local CPU core ID in the interrupt handler function. I want to see how my interruptions are distributed among different CPU cores under different conditions.
How should I do that?
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On March 8, 2015 8:37:23 PM EDT, Anish Kumar <anish198519851985@gmail.com> wrote:
You can use ftrace and such.
That only traces file related calls and not interrupts. I stand by either using the proc/interrupts file and updating the refresh rate to 1 second if possible. There may also debugging features that you may use for monitoring interrupts when setting the kernel's compile options in the menu for debugging. I am afraid I don't remember the exact configurations to set through Matwey. Please don't let all the ideas scare you Marley as your question was rather valid and we are trying to answer with only the information given to us. If can try to resend a more detailed question this would help a lot. Also thanks for helping through Anish and good idea but it doesn't trace interrupts directly. Nick
On Mar 8, 2015, at 12:06 PM, Matwey V. Kornilov <matwey.kornilov@gmail.com> wrote:
Hi,
I would like to somehow obtain local CPU core ID in the interrupt handler function. I want to see how my interruptions are distributed among different CPU cores under different conditions.
How should I do that?
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Many thanks for all answers. smp_processor_id() works just fine in interrupt context. Unfortunately /proc/interrupts is not what I was looking for. My idea was to print a line to dmesg at every interrupt to have a timestamp like the following: [ 926.440799] Enter intr at 0 [ 926.441059] Exit intr at 0
-----Original Message----- From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies-bounces@kernelnewbies.org] On Behalf Of Matwey V. Kornilov Sent: Monday, March 09, 2015 8:35 AM To: kernelnewbies@kernelnewbies.org Subject: Re: Get local CPU id Many thanks for all answers. smp_processor_id() works just fine in interrupt context. Unfortunately /proc/interrupts is not what I was looking for. My idea was to print a line to dmesg at every interrupt to have a timestamp like the following: [ 926.440799] Enter intr at 0 [ 926.441059] Exit intr at 0 Every interrupt? You might want to spend some time thinking about which interrupts you don't want to do the above printing for. Jeff Haran
On Mon, Mar 9, 2015 at 12:26 PM, Jeff Haran <Jeff.Haran@citrix.com> wrote:
-----Original Message----- From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies-bounces@kernelnewbies.org] On Behalf Of Matwey V. Kornilov Sent: Monday, March 09, 2015 8:35 AM To: kernelnewbies@kernelnewbies.org Subject: Re: Get local CPU id
Many thanks for all answers. smp_processor_id() works just fine in interrupt context.
Unfortunately /proc/interrupts is not what I was looking for. My idea was to print a line to dmesg at every interrupt to have a timestamp like the following:
[ 926.440799] Enter intr at 0 [ 926.441059] Exit intr at 0
Every interrupt? You might want to spend some time thinking about which interrupts you don't want to do the above printing for.
Jeff Haran
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies Jeff, He can just limit the dmesg output by using console_limit I believe. Nick
On March 9, 2015 2:10:57 PM EDT, Valdis.Kletnieks@vt.edu wrote:
On Mon, 09 Mar 2015 13:42:04 -0400, Nick Krause said:
He can just limit the dmesg output by using console_limit I believe.
Won't fly.
Hint:
How high to you have to set that limit to get through boot?
What happens if the message is logged to a console? I thought there was a way to limit messages to the console, however I don't remember the exact way. So yes you do have a valid point about rate limiting console messages. Nick
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
participants (7)
-
Anish Kumar -
Jeff Haran -
Matwey V. Kornilov -
Maxime Ripard -
Nicholas Krause -
Nick Krause
-
Valdis.Kletnieks＠vt.edu