Re: do_softirq() newbie question...

From: J. Robert von Behren (jrvb@cs.berkeley.edu)
Date: Tue Jun 13 2000 - 15:14:05 EST


Manfred Spraul wrote:

> The asm code is also the answer to your do_softirq question: do_softirq
> reenables the interrupt processing, and the kernel profiler uses
> interrupts --> you see lots of hits on
>
> local_irq_enable();
>
> IIRC some tools can profile areas that run with disabled interrupts, but
> I never used them.

Hey Manfred -

Something similar to this had occurred to me, but in looking at
do_softirq(), it doesn't seem like this could be the problem.
do_softirq() only has interrupts disabled across a couple of mask
operations and a few conditionals - not enough to make it likely that
the profiling interrupts would occur while interrupts were disabled. As
a sanity check, I've marked the lines that get executed with interrupts
disabled below:

asmlinkage void do_softirq()
{
        int cpu = smp_processor_id();
        __u32 active, mask;

        if (in_interrupt())
                return;

        local_bh_disable();

* local_irq_disable();
* mask = softirq_state[cpu].mask;
* active = softirq_state[cpu].active & mask;
*
* if (active) {
* struct softirq_action *h;
*
restart:
* /* Reset active bitmask before enabling irqs */
* softirq_state[cpu].active &= ~active;
*
* local_irq_enable();

                h = softirq_vec;
                mask &= ~active;

                do {
                        if (active & 1)
                                h->action(h);
                        h++;
                        active >>= 1;
                } while (active);

* local_irq_disable();
*
* active = softirq_state[cpu].active;
* if ((active &= mask) != 0)
* goto retry;
* }
*
* local_bh_enable();
*
* /* Leave with locally disabled hard irqs. It is critical to close
* * window for infinite recursion, while we help local bh count,
* * it protected us. Now we are defenceless.
* */
* return;
*
retry:
* goto restart;
}

The only potentially long-running bit is the h->action(h) call, but it
seems like the profiling interrupts should be able to look into this
without difficulty.

Am I missing something here? ;-)

-Rob

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:29 EST