>> 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->???.
>
>Easy to find out. Add a check for in_interrupt() in get_current and complain
>loudly.
I can' t use in_interrupt() since it uses current ;-).
>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.
Agreed, but I am not sure how much is trivial to implement that. When the
second interrupt happen the stack used by all exception routines and from
the do_IRQ() function will continue to be the same of the first interrupt?
If so it' s trivial to implement and we could allocate a per CPU 32kbyte
stack to take the full advantage of my new stack-trick.
>> What does it mean fake current? Which is the good idea?
>A complete "fake" task_structure at the bottom of the irq stack.
Sound doable in the per CPU irq stack design but using the current
implementation of current-> we are forced to use a stack of 8kbyte and not
more though. The fake struct would allow us to access current-> as usual
and after the interrupt I could copy the modifyed fake current in the real
current (in the real kernel stack).
>The advantage is that the same functions that access tasks could be
>used in interrupt context.
Yes.
>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.
And if a page fault would happen in a irq handler that is using my stack?
Another way to handle current-> right could be to make current-> more
smart (and less efficient of course ;-) to detect if it has to take
current from the stack or from the old stack. This would slow down every
current call but it would save us to copy data every interrupt or to
define a new irq_current.
The irq_current should be the fastest (and nasty and annoying) way to
do the thing...
Which way I should take?
1. fake current (2 memcpy(x,x,sizeof(struct task_struct)) per
first interrupt, current remains fast as now.
2. magic current (it detects if it has to take current from eip
or from the real kernel stack), there are not memcpy per interrupt
but current-> will have to check a bit flag every time is called.
3. irq_current (current-> in every irq handler must be replaced with
irq_current), no performance penalities but broke the kernel interface
for device drivers.
4. Don' t implement this per CPU interrupt stack because it' s no useful
and I am wasting my time ;-). I think it could be useful but I have
not a _lot_ of experience to be really sure. I think that the kernel
should become more stable in condition of _lot_ of nested interrupts
(and a bit I hope that then we could not need a 8kbyte kernel
stack ;-). I will implement also a kernel-maximum-stack-used-detector
in the patch-ikd soon (there' s just a KMAGICSTACK option but if I
remeber well, it should not tell us which is the maximum size of
kernel stack used since the boot, it should tell us only when the
kernel grows up over a certain limit or is overflowed...). This new ikd
option should tell us how much we really need a 8kbyte of kernel stack
(and how much my per-CPU irq stack helps).
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