Messages in this thread | | | Date | Thu, 16 Jul 1998 16:29:55 +0200 (MET DST) | From | Andrea Arcangeli <> | Subject | Re: per interrupt stack [was Re: Strange interrupt behaviour] |
| |
On Thu, 16 Jul 1998, Andi Kleen wrote:
> Umm, no. The paths that sends signals to processes (SIGSEGV, SIGBUS etc.) > have their own handlers and are not dispatched through the usual do_IRQ(). > You'll see that if you follow the interrupt entry code in entry.S.
I' ll take a look... What I need to know is _why_ my kernel locked yesterday. As Ingo predicted (if I have understood well its sentence too) I think it was due an irq handler that tried to change current->???.
> 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)...
> Also for Ctrl-C - C-c is of course not send to current. It is send to > the session leader of the terminal session associated with the tty C-c ^^^^^^^^^^^^^^ Woops, right!!!!
> occured on.
> > 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?
> interrupt/non interrupt versions then.
I don' t understand very well this but we could always define a irq_smp_processor_id() that uses irq_current-> instead of current->. Looking at the current-> implementation I can' t see a way to avoid the irq_current specific function. irq speicifc functions are ugly but we know that we are on a interrupt and we can' t do a lot of other things (and so we must handle a lot of other exception) so they don' t worry me a lot.
Andrea[s] Arcangeli
- 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
| |