Hi Walt,
I adjusted that list-attr.sm implementation in trunk to use the
mechanism you added. It seems to work fine and it looks much cleaner.
FYI, to follow up on the theory that the parallel sm version of
list-attr.sm would be a little faster, I did some simple timing of
pvfs2-lsplus on a directory with 10,000 files on a single server file
system. It turns out to be about 10% faster using the pjmp approach.
pvfs2-lsplus is reading 32 entries at a time so that results in 32
nested parallel machines for each iteration.
(here is the link to the original email about what's going on there):
http://www.beowulf-underground.org/pipermail/pvfs2-developers/2008-March/003947.html
-Phil
I've implemented the changes we discussed to the state machine.
I've tested basic functionality and everything seems to be working fine.
No big surprise, wasn't too big a deal.
What do you guys want? Do you want me to commit the changes, or send
out a patch or what? The changes are confined to the two SM files (.c
and .h) so backing out a commit later is no biggie.
BTW, Sam, it turns out the SMCB already had a pointer to it's parent
SMCB, so it IS possible to get to the parent and sibling frames - it
just isn't very convenient. All we'd have to do is add an access
function or two.
Let me know what you want.
Walt
--
Dr. Walter B. Ligon III
Associate Professor
ECE Department
Clemson University
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
