is it possible to liimit the softirq re entrance times

linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed

* is it possible to liimit the softirq re entrance times
@ 2015-08-20 17:09 vichy
  2015-08-20 20:05 ` Russell King - ARM Linux
  0 siblings, 1 reply; 3+ messages in thread
From: vichy @ 2015-08-20 17:09 UTC (permalink / raw)
  To: linux-arm-kernel

After I tracing softirq flow in ARM platform, I have some colusion like below:
1. softirq is running at the end of any irq context, when irq is eabled.
2. as long as any Hard irq happen, softirq can be interrupt and reentrant

My question are:
1. in __do_sofiq, there is a jiffies setting to make sure the whole
softirq will not took to long.
But in my case is there any many hard irq happen like below

                        trace_softirq_entry(vec_nr);    ------a
                        h->action(h);
                        trace_softirq_exit(vec_nr);      ---------b

from lttng, I see there 100 interrupt happen from entry to exit.

is there kernel config or module parameter to let me down grade the
hard irq count from 100  --> 80 or 90 and event can controlled me.
I don't mean I control the count of hard irq, but I found this softirq
is interrupt by 80 times.
then I will not enable_irq until I finished the job.

if no, isn't it possible to make starvation in above a and b?

really appreciate ur kind help,

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

* is it possible to liimit the softirq re entrance times
  2015-08-20 17:09 is it possible to liimit the softirq re entrance times vichy
@ 2015-08-20 20:05 ` Russell King - ARM Linux
  2015-08-21  5:27   ` vichy
  0 siblings, 1 reply; 3+ messages in thread
From: Russell King - ARM Linux @ 2015-08-20 20:05 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Aug 21, 2015 at 01:09:23AM +0800, vichy wrote:
> My question are:
> 1. in __do_sofiq, there is a jiffies setting to make sure the whole
> softirq will not took to long.
> But in my case is there any many hard irq happen like below
> 
>                         trace_softirq_entry(vec_nr);    ------a
>                         h->action(h);
>                         trace_softirq_exit(vec_nr);      ---------b
> 
> from lttng, I see there 100 interrupt happen from entry to exit.

Firstly, I don't trust the trace infrastructure all that much for
performance measurements: it has a non-zero overhead (especially if
you turn on stack tracing), and if you want to do these kinds of
measurements, you first need to ascertain what that overhead is, so
you can subtract the effect of having trace enabled from the
observations.  It's quite possible that a number of those 100
interrupts are happening in the trace code recording the softirq
entry and exit events.

Secondly, you seem to be saying that 100 interrupts happen in
h->action().  You don't specify the frequency of those interrupts.
You also don't mention (which is more important) how long h->action()
takes to run.  You also don't say which softirq it is.

>From the sounds of it, whatever soft irq handler is running, it's the
handler itself which is the cause of your problem, but not knowing any
of the details in my second point above, it's impossible to tell.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

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

* is it possible to liimit the softirq re entrance times
  2015-08-20 20:05 ` Russell King - ARM Linux
@ 2015-08-21  5:27   ` vichy
  0 siblings, 0 replies; 3+ messages in thread
From: vichy @ 2015-08-21  5:27 UTC (permalink / raw)
  To: linux-arm-kernel

hi Russel:

2015-08-21 4:05 GMT+08:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Fri, Aug 21, 2015 at 01:09:23AM +0800, vichy wrote:
>> My question are:
>> 1. in __do_sofiq, there is a jiffies setting to make sure the whole
>> softirq will not took to long.
>> But in my case is there any many hard irq happen like below
>>
>>                         trace_softirq_entry(vec_nr);    ------a
>>                         h->action(h);
>>                         trace_softirq_exit(vec_nr);      ---------b
>>
>> from lttng, I see there 100 interrupt happen from entry to exit.
>
> Firstly, I don't trust the trace infrastructure all that much for
> performance measurements: it has a non-zero overhead (especially if
> you turn on stack tracing), and if you want to do these kinds of
> measurements, you first need to ascertain what that overhead is, so
> you can subtract the effect of having trace enabled from the
> observations.  It's quite possible that a number of those 100
> interrupts are happening in the trace code recording the softirq
> entry and exit events.
>
> Secondly, you seem to be saying that 100 interrupts happen in
> h->action().  You don't specify the frequency of those interrupts.
> You also don't mention (which is more important) how long h->action()
> takes to run.  You also don't say which softirq it is.
I pasted some part of trace I captured as below.

>
> From the sounds of it, whatever soft irq handler is running, it's the
> handler itself which is the cause of your problem, but not knowing any
> of the details in my second point above, it's impossible to tell.

I paste the log I got from trace
>You don't specify the frequency of those interrupts.
those are ramdomly happen because usb devices is receiving/sending data.
> You also don't mention (which is more important) how long h->action()
it is about 12.915016ms
> takes to run.  You also don't say which softirq it is.
the sofirq vec =1, from the kernel define, it should be TIMER_SOFTIRQ

Isn't there any upward bound for softirq interruptted by HW irq?

Sincerely appreciate your kind explaination,


enum
{
        HI_SOFTIRQ=0,
        TIMER_SOFTIRQ,
        NET_TX_SOFTIRQ,
        NET_RX_SOFTIRQ,
        BLOCK_SOFTIRQ,
        BLOCK_IOPOLL_SOFTIRQ,
        TASKLET_SOFTIRQ,
        SCHED_SOFTIRQ,
        HRTIMER_SOFTIRQ,
        RCU_SOFTIRQ,    /* Preferable RCU should always be the last softirq */

        NR_SOFTIRQS
};

43:08.755 688 556        bla_0        0        softirq_entry
vec=1        3        20
43:08.755 895 172        bla_0        0        irq_handler_entry
 irq=87, name=ehci_hcd:usb3        3        20
43:08.755 993 380        bla_0        0        mm_page_alloc
page=0xeb124c00, order=3, gfp_flags=16928, migratetype=0        3
  20
43:08.756 178 924        bla_0        0        irq_handler_exit
irq=87, ret=1        3        20
43:08.756 190 100        bla_0        0        irq_handler_entry
 irq=87, name=ehci_hcd:usb3        3        20
43:08.756 244 276        bla_0        0        irq_handler_exit
irq=87, ret=1        3        20
43:08.756 396 860        bla_0        0        irq_handler_entry
 irq=87, name=ehci_hcd:usb3        3        20
43:08.757 002 436        bla_0        0        irq_handler_entry
 irq=29, name=twd        3        20
43:08.757 040 244        bla_0        0        irq_handler_exit
irq=29, ret=1        3        20
43:08.757 046 268        bla_0        0        irq_handler_entry
 irq=87, name=ehci_hcd:usb3        3        20
43:08.757 785 772        bla_0        0        irq_handler_exit
irq=87, ret=1        3        20
43:08.757 800 220        bla_0        0        irq_handler_entry
 irq=87, name=ehci_hcd:usb3        3        20
43:08.758 586 644        bla_0        0        irq_handler_exit
irq=87, ret=1        3        20
43:08.758 598 196        bla_0        0        irq_handler_entry
 irq=87, name=ehci_hcd:usb3        3        20
43:08.759 040 900        bla_0        0        irq_handler_exit
irq=87, ret=1        3        20
43:08.759 113 724        bla_0        0        irq_handler_entry
 irq=87, name=ehci_hcd:usb3        3        20
43:08.759 480 276        bla_0        0        mm_page_alloc
page=0xeb11ff00, order=3, gfp_flags=16928, migratetype=0        3
  20
43:08.759 663 100        bla_0        0        irq_handler_exit
irq=87, ret=1        3        20
43:08.759 675 884        bla_0        0        irq_handler_entry
 irq=87, name=ehci_hcd:usb3        3        20
43:08.760 020 468        bla_0        0        irq_handler_exit
irq=87, ret=1        3        20
43:08.760 030 604        bla_0        0        irq_handler_entry
 irq=87, name=ehci_hcd:usb3        3        20
43:08.760 388 452        bla_0        0        irq_handler_exit
irq=87, ret=1        3        20
43:08.760 398 484        bla_0        0        irq_handler_entry
 irq=87, name=ehci_hcd:usb3        3        20
43:08.760 980 348        bla_0        0        irq_handler_exit
irq=87, ret=1        3        20
43:08.760 989 820        bla_0        0        irq_handler_entry
 irq=29, name=twd        3        20
43:08.761 029 324        bla_0        0        irq_handler_exit
irq=29, ret=1        3        20
43:08.761 035 908        bla_0        0        irq_handler_entry
 irq=87, name=ehci_hcd:usb3        3        20
43:08.761 753 780        bla_0        0        irq_handler_exit
irq=87, ret=1        3        20
43:08.761 767 956        bla_0        0        irq_handler_entry
 irq=87, name=ehci_hcd:usb3        3        20
43:08.762 125 924        bla_0        0        irq_handler_exit
irq=87, ret=1        3        20
43:08.762 135 964        bla_0        0        irq_handler_entry
 irq=87, name=ehci_hcd:usb3        3        20
43:08.762 190 300        bla_0        0        irq_handler_exit
irq=87, ret=1        3        20
43:08.762 276 580        bla_0        0        irq_handler_entry
 irq=87, name=ehci_hcd:usb3        3        20
43:08.762 733 724        bla_0        0        mm_page_alloc
page=0xeb12be00, order=3, gfp_flags=16928, migratetype=0        3
  20
43:08.762 943 404        bla_0        0        irq_handler_exit
irq=87, ret=1        3        20
43:08.762 963 852        bla_0        0        irq_handler_entry
 irq=87, name=ehci_hcd:usb3        3        20
43:08.763 678 020        bla_0        0        irq_handler_exit
irq=87, ret=1        3        20
43:08.763 689 796        bla_0        0        irq_handler_entry
 irq=87, name=ehci_hcd:usb3        3        20
43:08.764 390 884        bla_0        0        irq_handler_exit
irq=87, ret=1        3        20
43:08.764 402 372        bla_0        0        irq_handler_entry
 irq=29, name=twd        3        20
43:08.765 204 812        bla_0        0        irq_handler_exit
irq=29, ret=1        3        20
43:08.765 216 436        bla_0        0        irq_handler_entry
 irq=41, name=irq        3        20
43:08.765 242 924        bla_0        0        irq_handler_exit
irq=41, ret=1        3        20
43:08.765 264 092        bla_0        0        irq_handler_entry
 irq=53, name=irq        3        20
43:08.765 269 276        bla_0        0        irq_handler_exit
irq=53, ret=1        3        20
43:08.765 274 644        bla_0        0        irq_handler_entry
 irq=54, name=irq        3        20
43:08.765 290 572        bla_0        0        irq_handler_exit
irq=54, ret=1        3        20
43:08.765 298 316        bla_0        0        irq_handler_entry
 irq=55, name=irq        3        20
43:08.765 423 564        bla_0        0        irq_handler_exit
irq=55, ret=1        3        20
43:08.765 433 724        bla_0        0        irq_handler_entry
 irq=80, name=irq        3        20
43:08.765 450 188        bla_0        0        irq_handler_exit
irq=80, ret=1        3        20
43:08.765 456 628        bla_0        0        irq_handler_entry
 irq=87, name=ehci_hcd:usb3        3        20
43:08.765 711 252        bla_0        0        mm_page_alloc
page=0xeb123f40, order=1, gfp_flags=2118176, migratetype=0        3
    20
43:08.766 252 228        bla_0        0        irq_handler_exit
irq=87, ret=1        3        20
43:08.766 266 716        bla_0        0        irq_handler_entry
 irq=54, name=irq        3        20
43:08.766 282 220        bla_0        0        irq_handler_exit
irq=54, ret=1        3        20
43:08.766 288 460        bla_0        0        irq_handler_entry
 irq=87, name=ehci_hcd:usb3        3        20
43:08.766 550 108        bla_0        0        mm_page_alloc
page=0xeb12b600, order=3, gfp_flags=16928, migratetype=0        3
  20
43:08.767 185 100        bla_0        0        irq_handler_exit
irq=87, ret=1        3        20
43:08.767 203 156        bla_0        0        irq_handler_entry
 irq=87, name=ehci_hcd:usb3        3        20
43:08.767 949 260        bla_0        0        irq_handler_exit
irq=87, ret=1        3        20
43:08.767 960 020        bla_0        0        irq_handler_entry
 irq=87, name=ehci_hcd:usb3        3        20
43:08.768 395 340        bla_0        0        irq_handler_exit
irq=87, ret=1        3        20
43:08.768 496 332        bla_0        0        irq_handler_entry
 irq=29, name=twd        3        20
43:08.768 537 452        bla_0        0        irq_handler_exit
irq=29, ret=1        3        20
43:08.768 603 572        bla_0        0        softirq_exit
vec=1        3        20

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

end of thread, other threads:[~2015-08-21  5:27 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-08-20 17:09 is it possible to liimit the softirq re entrance times vichy
2015-08-20 20:05 ` Russell King - ARM Linux
2015-08-21  5:27   ` vichy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).