Most of the cases you see in libMicro today arose from specific investigations. For example, we would get a syscall profile from a SPECweb99 test rig and then build libMicro cases to home in on specific, significant APIs. However, we always intended libMicro to be extensible, and sometimes we extended it arbitrarily in certain directions just to show off. The reason "pipe" doesn't already do what you suggest is that there was no pressing need at the time (or we just got bored)!
"pipe" is a pretty weird case in the libMicro scheme of things. Once we move outside of the "st" cases "pipe" does begin to fall outside the libMicro design sweet spot with its use of helper threads (which introduce issues such as scheduler latency, cache affinity etc.). Yet it does begin to show how libMicro can be more widely applied.
Indeed, I think you'll find libMicro has many uses outside raw microbenchmarking. For instance, I found libMicro really useful as a framework when it came to stress-testing my fixes to getenv(3C) and process shared rwlocks (particularly because support for multiple threads and/or processes is fundamental to our design).
Of course, it may be time to think about splitting "pipe" into transport-specific cases (which is what I did with the "cascade" cases).
We also need to give some thought to what becomes of the "bench" script. Just because we can test something doesn't mean we should test it by default. We already test some fairly boring cases, some of which were included just to show off how configurable libMicro is. And, of course, there is loads of stuff which we could and should test today, but which has yet to make it into the "bench" script (e.g. more thread scalability stuff). We have some ideas, but we'd love to hear (and see!) yours too.
Cheers, Phil Alexander Kolbasov wrote:
I think that the pipe test for libMicro can be enhanced a bit by - Adding support for PF_UNIX/SOCK_DGRAM socketsThey are used by various applications and it is interesting to measure performance differencies from other loopback-type transports- Adding support for ptys as a loopback pipe mechanism.- Supporting Solaris pipes in normal and STREAMS modes. This change is only valid for STREAMS-based implementations.I also have a prototype that allows pushing arbitrary STREAMS modules on both read and write sides of the pipeline. This allows to measure the impact various STREAMS modules have on performance.__ Alexander Kolbasov, Solaris Kernel Performance team. _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
