> 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.
Agreed. Probably I have not thought at the MMU trick because I don' t know
how to implement it ;-).
> There is a per-schedule() 32-bit write to the kernel page table, and an
So every shedule we will need to remap the low 4kbyte of every irq stack
as the low 4kbyte of the kernel stack of the new current process. This has
to be done in O(NR_IRQ*num_cpus). I don' t know how it' s possible to do
that in a 32bit write.
> 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
This for decrease of tick current->real->counter I guess from your new
email.
> This way we get both of the two worlds, speed from the %esp trick and
> robustness from separated stacks.
Agreed.
Now the my developing is stalled for awhile since I had to study the x86
MMU to implement the schedule() thing... ;-).
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