Easy to find out. Add a check for in_interrupt() in get_current and complain
loudly.
>
> > This means your patch never touched them. On the other hand it might be
> > a good idea to give them their own stacks too - simply to increase locality
> > (this needs profiling)
>
> OK. Thinking about the static area, 4kbyte of stack per interrupt x 16
> interrupt is not an issue. In a SMP machine instead my last stuff alloc
> 4kbyte x NR_IRQS x NR_CPUS. This mean 4k x 16(or more, I don' t know how
> SMP handle irq) x NR_CPUS. If NR_CPUS is really 32 the stack area would be
> really a waste and it would be better to allocate the 4kbyte stack in
> request_irq getting a free dynamic page (maybe using some triks to not
> allocate 32 dynamic page per interrupt in SMP)...
I do not understand why you want per-interrupt stacks. I think a per-CPU
stack that is shared by all interrupts is enough. If the kernel currently
runs stable with a effective 7K stack (and 2.0 with a 3 interrupt stack),
then 8 or 16KB of per-CPU global interrupt stack should be plenty.
> > > Hmm changing current to irq_current inside the irq_handlers sound very
> > > simpler and cleaner to me.
> >
> > Have to check if none of the SMP locking routines (spinlocks etc.) access
> > smp_processor_id(), otherwise it'll break. If it turns out that they do
> > the fake current is probably a good idea still, because it avoids to define
>
> What does it mean fake current? Which is the good idea?
A complete "fake" task_structure at the bottom of the irq stack.
The advantage is that the same functions that access tasks could be
used in interrupt context.
Of course this trick can only be used for hardware driver IRQs and bottom
halves,, but not for things like page faults, math emulaton etc, because
these really require process context.
-Andi
-
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.altern.org/andrebalsa/doc/lkml-faq.html