Thanks for the detailed explanation Phil. I hadn't thought about the
context switches that might slow down flow. I was primarily thinking
of something that would be cleaner, and easier to modify and test for
different scenarios. If at some point I get around to playing with a
flow impl that uses the concurrent state machine framework, I'll open
up the discussion again to avoid any of the pitfalls you described.
Cleaner and easier to modify would be great!
I just remembered that there are a couple of test programs in the tree
to look at the thread context switch overhead, in case they are helpful
to figure out if it is still a concern:
pvfs2/test/io/job/thread-bench2.c
pvfs2/test/io/job/thread-bench3.c
One of those just goes through a bunch of iterations relaying a
condition across threads to see how long it takes. The second one does
the same thing, except with 2 relays instead of one (to mimic the trove
side of things). I haven't run these on a decent machine in years. I
will also add a disclaimer that the test programs are old and quite
possibly wrong :)
We also have the benefit of your small-io optimization now too, so it
isn't quite as critical as it used to be for the flow to be able to keep
the latency down on small transfers any more...
-Phil
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
