[Pvfs2-developers] list-attr.sm refactored with pjmp
walt
walt at CLEMSON.EDU
Thu Mar 13 14:46:17 EST 2008
Patch is attatched - based on the top of the trunk - it is only the
changes to PINT_sm_frame
The way this works is when a SM DOES A PJMP it pushes it's children's
frames. The children will each get their own SMCB, so if they run a
PJMP they will have their own stack. So, when you return to a parent
its frame will be at PINT_sm_frame(smcb, -1). It is probably a good
idea to store the number of children somewhere in the parent's frame so
you can pop them off.
We should create a #define for that -1 in state_machine.h You can
access the children frames to retrieve results with indexes 0 .. N-1 or
pop them off one at a time.
There is no way to jump to the bottom of the stack. Nested machines do
not change frames, so they aren't an issue.
Walt
Phil Carns wrote:
> Ok. I have fixed that "only zero indexes work" issue in trunk too in
> order to be able to index 0..N, but I didn't do anything beyond that
> with it. If you have a patch with your sm code changes that we can go
> ahead and push to trunk that would be great.
>
> You might want to go ahead and consider merging some of these other
> recent changes to trunk into your branch as well. Some things here from
> about the 11th of this month and newer might be relevant for what you
> are working on. There are some generic fixes to sm / pjmp
> functionality, and also some cleanup of getattr_work that makes it a
> little safer to call from other parents:
>
> http://www.pvfs.org/fisheye/changelog/~br=MAIN,author=pcarns/PVFS
>
> So would a -1 index get you the very outermost parent (ie, the bottom of
> the stack)? In the more general case it may still be helpful to just
> get to the level right before pjmp rather than all the way to the
> bottom, particularly if the pjmp is issued from a nested machine.
>
> -Phil
>
> walt wrote:
>> Phil, I'll look at the code when I can. I'm interested in the
>> get_attr_work issue, we are calling that in the create_file request,
>> and we have also created a set_attr_work SM and will likely be
>> setting up some others in our work. At minimum we need to document
>> the parameters in the code. Whatever gets done here we will probably
>> want to make sure it gets replicated in the trunk as well as our branch.
>>
>> Also, in our branch I have modified the parallel state machine code a
>> little to fix the problem you mentioned wrt getting the parent frame.
>> In the version we checked out of trunk, only a zero index could be
>> specified - otherwise an infinite loop resulted. Also, it seemed to
>> assume a positive index. I modified it to allow both positive and
>> negative indexes, so a -1 index would give you the parent frame, and
>> 0..N gives the frames on top of the stack (which is actually circular).
>>
>> Pretty simple mod actually, I can try to create a patch for it and you
>> can try it out.
>>
>> Keep me up to date on that other issue.
>>
>> Walt
>>
>> Phil Carns wrote:
>>> I needed to make some changes to list-attr.sm recently and realized
>>> that it probably should really be redone now that we have parallel
>>> nested machines available. listattr is a server operation that
>>> retrieves attributes for a list of handles at once. The old version
>>> duplicated logic from get-attr.sm, while the new version does a pjmp
>>> to the nested pvfs2_get_attr_work_sm machine instead.
>>>
>>> There are a few advantages to this approach:
>>>
>>> - it gives us a complete example of pjmp in trunk
>>> - we don't have to keep listattr code in sync with getattr, since
>>> they now share the same core logic (listattr was already a little
>>> behind)
>>> - the list-attr.sm source code is much smaller now
>>> - list-attr.sm should be faster now as well, because it is capable of
>>> getting many trove operations queued up at once rather than iterating
>>> through each of the getattr's (and waiting for completion of each) in
>>> serial
>>>
>>> I could stand some extra eyes to look at list-attr.sm and make sure
>>> the implementation in trunk is sane. Here is a link if anyone wants
>>> to look at it online:
>>>
>>> http://www.pvfs.org/fisheye/browse/~raw,r=1.9/PVFS/src/server/list-attr.sm
>>>
>>>
>>> There are two goofy bits of code marked with a "TODO" comment:
>>>
>>> - Running pvfs2_get_attr_work_sm requires setting a variety of
>>> undocumented parameters before launching it. I'm not sure how to
>>> best clean this up (or if I should just let this slide for now).
>>>
>>> - After the pjmp, it is a little hard to find the parent frame (which
>>> is useful to have before popping the other frames so that you have
>>> somewhere to store results). I ended up just iterating through the
>>> frames looking for it, but I would like to find a nicer way to do
>>> this too.
>>>
>>> -Phil
>>> _______________________________________________
>>> Pvfs2-developers mailing list
>>> Pvfs2-developers at beowulf-underground.org
>>> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
-------------- next part --------------
--- pvfs2/src/common/misc/state-machine-fns.c 2008-03-13 15:00:40.000000000 -0400
+++ pvfs-cu/src/common/misc/state-machine-fns.c 2008-03-13 15:34:43.000000000 -0400
@@ -605,7 +605,7 @@
void *PINT_sm_frame(struct PINT_smcb *smcb, int index)
{
struct PINT_frame_s *frame_entry;
- struct qlist_head *next;
+ struct qlist_head *target;
if(qlist_empty(&smcb->frames))
{
@@ -616,15 +616,21 @@
}
else
{
- int i = 0;
-
- next = smcb->frames.next;
- while(i < index)
+ /* frame list is circular */
+ target = smcb->frames.next;
+ /* this handles negative indexes */
+ while(index < 0)
+ {
+ target = target->prev;
+ index++;
+ }
+ /* this handles positive indexes */
+ while(index > 0)
{
- i++;
- next = next->next;
+ target = target->next;
+ index--;
}
- frame_entry = qlist_entry(next, struct PINT_frame_s, link);
+ frame_entry = qlist_entry(target, struct PINT_frame_s, link);
return frame_entry->frame;
}
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: walt.vcf
Type: text/x-vcard
Size: 229 bytes
Desc: not available
Url : http://www.beowulf-underground.org/pipermail/pvfs2-developers/attachments/20080313/45b843dd/walt.vcf
More information about the Pvfs2-developers
mailing list