|
Legion Runtime
|
#include <mapping.h>
Public Attributes | |
| std::vector< std::vector< PhysicalInstance > > | valid_instances |
| std::vector< std::vector< CollectiveView > > | valid_collectives |
| std::vector< unsigned > | premapped_regions |
| DomainPoint | shard |
| Domain | shard_domain |
| Processor | shard_processor |
| VariantID | shard_variant |
The map task call is performed on every task which is eagerly (as opposed to lazily) executed and has all its input already eagerly executed. The input to map_task consists of the names of any valid instances that the runtime knows about for each of the individual region requirements stored in 'valid_instances' (if the user requested them by setting 'valid_instances' to 'true' in the select_task_options mapper call), and the indexes of any regions which were premapped in 'premapped_regions'.
The mapper must first select a set of 'chosen_instances' to use for each region requirement of the task. Multiple instances can be chosen for each region requirement (hence the vector of vectors) but the runtime will use the first instance that has space for each field in the vector of instances for all the fields in the region requirement. For read-only region requirements, the mapper can optionally request that the runtime not track the instances used for read-only region requirements with the 'untracked_valid_regions'. This will ensure that read-only instances are not considered a long-term valid copy of the data and make them immediately eligible for garbage collection after the task is done mapping. Only the indexes of read-only region requirements should be specified.
In addition to mapping regions for the task, the mapper can also specify a memory to use for each of the futures of the task. The entries in this vector will be zipped with the vector of futures in the 'Task' object to determine which memory to map each future.
The mapper must also select a set of 'target_procs' that specifies the target processor(s) on which the task can run. If a single processor is chosen then the task is guaranteed to run on that processor. If multiple processors are specified, the runtime will run the task on the first procoessor that becomes available. All of the processors must be on the same node and of the same kind for now.
The mapper must further select a task variant to use to execute the task and specify its VariantID in 'chosen_variant'. This variant must have execution constraints consistent with all the 'target_procs'. All of the instances specified by 'chosen_instances' must be in memories visible to all the target processors or the variant must speicfy 'no_access' specialized constraints for such region requirements. The mapper can specify a priority for the task with the 'task_priority' field. This will allow the task to be re-ordered ahead of lower priority tasks and behind higher priority tasks by the runtime as it's being dynamically scheduled. Negative priorities are lower and positive priorities are higher. The 'copy_fill_priority' field can control the probabilities of any copies and fills performed on behalf of the task.
The mapper can request profiling information about this task as part of its execution. The mapper can specify a task profiling request set in 'task_prof_requests' for profiling statistics about the execution of the task. The mapper can also ask for profiling information for the copies generated as part of the mapping of the task through the 'copy_prof_requests' field. The 'profiling_priority' field indicates with which priority the profiling results should be send back to the mapper.
When selecting a leaf-task variant for the task, the mapper can use the 'leaf_pool_bounds' to specify sizes of memory pools for the runtime to allocate to handle dynamic memory allocations during the execution of the task. These must be big enough to handle all such dynamic memory allocations in each kind of memory. The mapper can use the value of zero to indicate that an "unbound" pool should be created which will block all future memory allocations in that memory until the task is done running (this will likely result in severe performance degradations). If the task variant also has statically specified pool bounds, then the dynamically sized upper bound provided by the mapper will override the static bound provided at the time of task variant registration.
Finally, the mapper can requrest a postmap_task mapper call be performed to make additional copies of any output regions of the task for resilience purposes by setting the 'postmap_task' flag to true.
If the mapper decides that it wants to abort the mapping of the task it can do that by setting the 'abort_mapping' flag. This will return the task back to the ready queue presented to the mapper by select_tasks_to_map mapper call.
1.9.8