* Mathieu Desnoyers <[email protected]> wrote:
> I'm worried about "self-recursion" behaviors that could be
> triggered though: if the userland callback code called from a page
> fault triggers a page fault all by itself, then it looks like a
> good way to bring the system to its knees. [...]
Not really, SIGIO isnt being reprocessed until the signal handler
returns.
> [...] The same apply to context switches. Do you have a way to
> handle this in mind ?
Shouldnt be a problem in theory: yes, in case of repeat migrations
repeat signals will be sent, but they should not nest in any nasty
fashion.
That's the theory, it needs checking! :-)
One furthr optimization would be possible: in case you think we can
write the signal handler in assembly or build it with gcc flags that
does not use SSE we might also add a 'lightweight signal handler'
kind of flag to the kernel, which does not save FPU/vector-CPU(SSE)
state. In this case signals become *really* fast on x86, almost as
fast as interrupts.
One detail: you'd not want to use a queueing signal, because the
siginfo queue might overflow. It's also unnecessary: RCU only needs
the last migration event, previous history is uninteresting.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
