![]() | ||||||||||
Messages in this thread |
> 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/ | |||||||||
| Last update: 2005-03-22 12:27 [from the cache] ©2003-2008 | ||||||||||