I think that we should reconsider including MPIT_PERFORMANCE_ALL as it currently exists in the MPIT proposal because it discourages libraries and layering among performance tools. If you have two tool libraries and one or both of them use MPIT_PERFORMANCE_ALL to start/stop their performance variables, the tools are likely to be incompatible. One of MPI's great strengths is providing support mechanisms for parallel libraries, I don't see why we should omit those mechanisms in the tools space. I understand the convenience and (potentially) performance arguments to be made for having functionality like this, but we might want to consider scoping it sort of like we do for communicators. Perhaps make it possible to group handles or open handles with an associated context of sorts to perform the group start/stop operations later. Alternatively, if there is no substantial performance argument to be made, we could just drop MPIT_PERFORMANCE_ALL altogether. A for-loop isn't particularly burdensome to tools/applications. I don't have a concrete alternative proposal here, I just wanted to bring up the issue for discussion. I unfortunately missed the last concall due to technical difficulties, so I wasn't able to bring it up there. -Dave