Messages in this thread |  | | | From | Alan Cox <> | | Subject | Re: context switch vs. signal delivery [was: Re: Accelerating user mode | | Date | Sat, 3 Aug 2002 08:33:30 -0400 (EDT) |
| |
> 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 ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |