All of lore.kernel.org
 help / color / mirror / Atom feed
* Get local CPU id
@ 2015-03-08 19:06 Matwey V. Kornilov
  2015-03-08 20:41 ` Nicholas Krause
                   ` (3 more replies)
  0 siblings, 4 replies; 15+ messages in thread
From: Matwey V. Kornilov @ 2015-03-08 19:06 UTC (permalink / raw)
  To: kernelnewbies

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?

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Get local CPU id
  2015-03-08 19:06 Get local CPU id Matwey V. Kornilov
@ 2015-03-08 20:41 ` Nicholas Krause
  2015-03-08 21:49 ` Maxime Ripard
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 15+ messages in thread
From: Nicholas Krause @ 2015-03-08 20:41 UTC (permalink / raw)
  To: kernelnewbies



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 at kernelnewbies.org
>http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Get local CPU id
  2015-03-08 19:06 Get local CPU id Matwey V. Kornilov
  2015-03-08 20:41 ` Nicholas Krause
@ 2015-03-08 21:49 ` Maxime Ripard
  2015-03-08 22:03   ` Nicholas Krause
  2015-03-08 22:30   ` Valdis.Kletnieks at vt.edu
  2015-03-09  0:37 ` Anish Kumar
  2015-03-09 15:35 ` Matwey V. Kornilov
  3 siblings, 2 replies; 15+ messages in thread
From: Maxime Ripard @ 2015-03-08 21:49 UTC (permalink / raw)
  To: kernelnewbies

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150308/864d20b8/attachment.bin 

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Get local CPU id
  2015-03-08 21:49 ` Maxime Ripard
@ 2015-03-08 22:03   ` Nicholas Krause
  2015-03-08 22:30   ` Valdis.Kletnieks at vt.edu
  1 sibling, 0 replies; 15+ messages in thread
From: Nicholas Krause @ 2015-03-08 22:03 UTC (permalink / raw)
  To: kernelnewbies



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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Get local CPU id
  2015-03-08 21:49 ` Maxime Ripard
  2015-03-08 22:03   ` Nicholas Krause
@ 2015-03-08 22:30   ` Valdis.Kletnieks at vt.edu
  2015-03-08 23:10     ` Nicholas Krause
  2015-03-09 12:59     ` Maxime Ripard
  1 sibling, 2 replies; 15+ messages in thread
From: Valdis.Kletnieks at vt.edu @ 2015-03-08 22:30 UTC (permalink / raw)
  To: kernelnewbies

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... :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150308/80f231b9/attachment.bin 

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Get local CPU id
  2015-03-08 22:30   ` Valdis.Kletnieks at vt.edu
@ 2015-03-08 23:10     ` Nicholas Krause
  2015-03-09 14:39       ` Maxime Ripard
  2015-03-09 12:59     ` Maxime Ripard
  1 sibling, 1 reply; 15+ messages in thread
From: Nicholas Krause @ 2015-03-08 23:10 UTC (permalink / raw)
  To: kernelnewbies



On March 8, 2015 6:30:47 PM EDT, Valdis.Kletnieks at 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 at kernelnewbies.org
>http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Get local CPU id
  2015-03-08 19:06 Get local CPU id Matwey V. Kornilov
  2015-03-08 20:41 ` Nicholas Krause
  2015-03-08 21:49 ` Maxime Ripard
@ 2015-03-09  0:37 ` Anish Kumar
  2015-03-09  0:52   ` Nicholas Krause
  2015-03-09 15:35 ` Matwey V. Kornilov
  3 siblings, 1 reply; 15+ messages in thread
From: Anish Kumar @ 2015-03-09  0:37 UTC (permalink / raw)
  To: kernelnewbies

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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Get local CPU id
  2015-03-09  0:37 ` Anish Kumar
@ 2015-03-09  0:52   ` Nicholas Krause
  0 siblings, 0 replies; 15+ messages in thread
From: Nicholas Krause @ 2015-03-09  0:52 UTC (permalink / raw)
  To: 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 at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>_______________________________________________
>Kernelnewbies mailing list
>Kernelnewbies at kernelnewbies.org
>http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Get local CPU id
  2015-03-08 22:30   ` Valdis.Kletnieks at vt.edu
  2015-03-08 23:10     ` Nicholas Krause
@ 2015-03-09 12:59     ` Maxime Ripard
  1 sibling, 0 replies; 15+ messages in thread
From: Maxime Ripard @ 2015-03-09 12:59 UTC (permalink / raw)
  To: kernelnewbies

On Sun, Mar 08, 2015 at 06:30:47PM -0400, Valdis.Kletnieks at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150309/d0fa3796/attachment.bin 

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Get local CPU id
  2015-03-08 23:10     ` Nicholas Krause
@ 2015-03-09 14:39       ` Maxime Ripard
  0 siblings, 0 replies; 15+ messages in thread
From: Maxime Ripard @ 2015-03-09 14:39 UTC (permalink / raw)
  To: kernelnewbies

On Sun, Mar 08, 2015 at 07:10:09PM -0400, Nicholas Krause wrote:
> 
> 
> On March 8, 2015 6:30:47 PM EDT, Valdis.Kletnieks at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150309/fef4482c/attachment.bin 

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Get local CPU id
  2015-03-08 19:06 Get local CPU id Matwey V. Kornilov
                   ` (2 preceding siblings ...)
  2015-03-09  0:37 ` Anish Kumar
@ 2015-03-09 15:35 ` Matwey V. Kornilov
  2015-03-09 16:26   ` Jeff Haran
  3 siblings, 1 reply; 15+ messages in thread
From: Matwey V. Kornilov @ 2015-03-09 15:35 UTC (permalink / raw)
  To: kernelnewbies


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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Get local CPU id
  2015-03-09 15:35 ` Matwey V. Kornilov
@ 2015-03-09 16:26   ` Jeff Haran
  2015-03-09 17:42     ` Nick Krause
  0 siblings, 1 reply; 15+ messages in thread
From: Jeff Haran @ 2015-03-09 16:26 UTC (permalink / raw)
  To: kernelnewbies

-----Original Message-----
From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies-bounces at kernelnewbies.org] On Behalf Of Matwey V. Kornilov
Sent: Monday, March 09, 2015 8:35 AM
To: kernelnewbies at 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Get local CPU id
  2015-03-09 16:26   ` Jeff Haran
@ 2015-03-09 17:42     ` Nick Krause
  2015-03-09 18:10       ` Valdis.Kletnieks at vt.edu
  0 siblings, 1 reply; 15+ messages in thread
From: Nick Krause @ 2015-03-09 17:42 UTC (permalink / raw)
  To: kernelnewbies

On Mon, Mar 9, 2015 at 12:26 PM, Jeff Haran <Jeff.Haran@citrix.com> wrote:
> -----Original Message-----
> From: kernelnewbies-bounces at kernelnewbies.org [mailto:kernelnewbies-bounces at kernelnewbies.org] On Behalf Of Matwey V. Kornilov
> Sent: Monday, March 09, 2015 8:35 AM
> To: kernelnewbies at 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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Jeff,
He can just limit the dmesg output by using console_limit I believe.
Nick

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Get local CPU id
  2015-03-09 17:42     ` Nick Krause
@ 2015-03-09 18:10       ` Valdis.Kletnieks at vt.edu
  2015-03-09 20:05         ` Nicholas Krause
  0 siblings, 1 reply; 15+ messages in thread
From: Valdis.Kletnieks at vt.edu @ 2015-03-09 18:10 UTC (permalink / raw)
  To: kernelnewbies

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150309/bbcfba5d/attachment.bin 

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Get local CPU id
  2015-03-09 18:10       ` Valdis.Kletnieks at vt.edu
@ 2015-03-09 20:05         ` Nicholas Krause
  0 siblings, 0 replies; 15+ messages in thread
From: Nicholas Krause @ 2015-03-09 20:05 UTC (permalink / raw)
  To: kernelnewbies



On March 9, 2015 2:10:57 PM EDT, Valdis.Kletnieks at 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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2015-03-09 20:05 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-08 19:06 Get local CPU id Matwey V. Kornilov
2015-03-08 20:41 ` Nicholas Krause
2015-03-08 21:49 ` Maxime Ripard
2015-03-08 22:03   ` Nicholas Krause
2015-03-08 22:30   ` Valdis.Kletnieks at vt.edu
2015-03-08 23:10     ` Nicholas Krause
2015-03-09 14:39       ` Maxime Ripard
2015-03-09 12:59     ` Maxime Ripard
2015-03-09  0:37 ` Anish Kumar
2015-03-09  0:52   ` Nicholas Krause
2015-03-09 15:35 ` Matwey V. Kornilov
2015-03-09 16:26   ` Jeff Haran
2015-03-09 17:42     ` Nick Krause
2015-03-09 18:10       ` Valdis.Kletnieks at vt.edu
2015-03-09 20:05         ` Nicholas Krause

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.