Re: context switch vs. signal delivery [was: Re: Accelerating user mode

[Alan Cox <alan@redhat.com>]

> actually the opposite is true, on a 2.2 GHz P4:
> 
>   $ ./lat_sig catch
>   Signal handler overhead: 3.091 microseconds
> 
>   $ ./lat_ctx -s 0 2
>   2 0.90
> 
> ie. *process to process* context switches are 3.4 times faster than signal
> delivery. Ie. we can switch to a helper thread and back, and still be
> faster than a *single* signal.

Thats interesting indeed. I'd not tried it with the O(1) scheduler.

> signals are in essence 'lightweight' threads created and destroyed for the
> purpose of a single asynchronous event, it's IMO a very inefficient and
> baroque concept for almost anything (but debugging and a number of very
> special uses). I'd guess that with a sane threading library a helper
> thread is faster for almost everything.

Which would argue UML ought to have a positively microkernel view of
syscalls - sending a message ?