> Right. Currently in the usual paths current is only used to compute
> smp_processor_id() early in do_IRQ. This is no problem because the old
> stack is probably still there. For later interrupts it makes not much sense
> to compute current. So either outlaw it (add a check to current for a few
> releases to catch it), or alternatively give the interrupts a special
> task_structure that stays static - an "interrupt thread". This thread is
> not scheduled, it just exists to have a current during interrupt processing.
or, (beware, it's going to be ugly), read-only map the task stack's
lower-4k as lower-4k of the IRQ handler. NOTE, there will be _no_ per-IRQ
MMU cost with this trick, and it's nice with SMP and threads too.
This way we will have a per-IRQ 4k stack (should be enough), and a
per-process 7k stack (more than enough). And IRQs can still use 'current'
in read-only mode. (as Andi has noticed, in 90% of the cases this is
smp_processor_id()). There will be no SMP problems as we have per-CPU IRQ
stacks mapped to special (high, just under 4G) virtual addresses.
There is a per-schedule() 32-bit write to the kernel page table, and an
invlpg instruction (10 cycles). But this invlpg will not be needed in most
of the cases, as at schedule() time we usually do a TLB flush anyway. The
only un-nice cost is that we will have to do a full TLB flush on x86 CPUs
that have no invlpg instruction (i486 and other older CPUs) when we do a
thread-thread schedule(). On SMP, no cross-CPU TLB invalidation needed, as
IRQ stacks will be per-CPU.
The only per-IRQ cost is the %esp switch/restore.
illegal write-access to 'current->' from IRQ handlers will be
automatically caught by the write-protection fault. To still allow
write-access is to convert write access to current->real-> access.
(current->real is set to the real 'current' at fork() time). There is
_much_ less write-access to 'current->'. (the only write-access from IRQ
contexts i know of is in update_process_times(), a per-timer-IRQ thing).
This way we get both of the two worlds, speed from the %esp trick and
robustness from separated stacks.
hm?
-- mingo
-
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