Each rule define an interval with the previous rule, and everything in an
interval will be bound the the rule with the next message size. You cannot
define a rule for a specific amount. Thus, the fact that the rules must be
ordered by message size was done by design.

Returning a NULL rule as suggested by Howard is even more confusing as with
this approach you don't even know what is used (as it will automatically
fall back to the default decision).

  George.


On Tue, May 19, 2015 at 11:57 PM, Howard Pritchard <hpprit...@gmail.com>
wrote:

> HI Gilles,
>
> First a disclaimer - I do not know what the intended design was nor where
> the design document
> for this feature is located.
>
> However, I would certainly prefer that if the communicator size wasn't
> specifically specified
> in the rule file, a fall back do-no-harm algorithm would be selected.
>
> Following the KISS principal I would go with 2) returning a NULL rule when
> there is no matching size in the rule file for the communicator in
> question.
>
> Howard
>
>
> 2015-05-19 20:05 GMT-06:00 Gilles Gouaillardet <gil...@rist.or.jp>:
>
> Folks,
>>
>> this is a follow-up of a discussion on the user ML started at
>> http://www.open-mpi.org/community/lists/users/2015/05/26882.php
>>
>> 1) it turns out the dynamic rule filename must be "sorted" :
>> - rules must be sorted by communicator size
>> - within a given communicator size, rules must be sorted by message size
>>
>> if not, some rules are silently skipped, which is counter intuitive imho.
>>
>>
>> 2) the algo picks the rule with the higher communicator size less or
>> equal than the current communicator size (same thing for message size).
>> The exception is if there are no such rule, the first rule is selected.
>> for example, if the config file has rules for comm size 4, 8 and 16
>> comm size 4 => pick rule for comm size 4
>> comm size 5 => pick rule for comm 4
>> comm size 8 => pick rule for comm 8
>> *but*
>> comm size 2 => pick rule for comm size 4 (!)
>> imho, this is also counter intuitive.
>> i would have expected no rule is picked and the default behaviour is used.
>>
>> Same thing applies for message sizes.
>>
>> Is this the intended design ?
>>
>> 1) can be solved by inserting some qsort calls after parsing the config
>> file.
>> 2) can be solved by returning a NULL rule instead of the first rule ( or
>> by automatically inserting a rule for comm size 0 (and message size 0) if
>> no such rule is present in the config file).
>>
>> any thoughts ?
>>
>> Cheers,
>>
>> Gilles
>> _______________________________________________
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post:
>> http://www.open-mpi.org/community/lists/devel/2015/05/17425.php
>>
>
>
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2015/05/17426.php
>

Reply via email to