> > > 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.
Has someone gone through the lat_ctx.c and lat_sig.c code and convinced
themselves these are measuring things which ought to be compared like this?
When I wrote that code I didn't anticipate this comparison, so somebody
should go look.
I'd suggest that if you want to measure how fast you can communicate using
signals versus pipes (or sockets or whatever), someone write up a test
which has two processes bounce a token between each other using signals
and then compare that with lat_pipe. It's not clear to me that you are
comparing apples to apples.
If someone does write the test, we'll add it to LMbench if it reveals
anything useful. It should be easy enough to do. I can do it if it
isn't obvious.
-- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - 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/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:27 EST