On Tue, 21 Feb 2012 09:54:04 +0530 Siddhesh Poyarekar <siddhesh.poyarekar@xxxxxxxxx> wrote: > Stack for a new thread is mapped by userspace code and passed via > sys_clone. This memory is currently seen as anonymous in > /proc/<pid>/maps, which makes it difficult to ascertain which mappings > are being used for thread stacks. This patch uses the individual task > stack pointers to determine which vmas are actually thread stacks. > > The display for maps, smaps and numa_maps is now different at the > thread group (/proc/PID/maps) and thread (/proc/PID/task/TID/maps) > levels. The idea is to give the mapping as the individual tasks see it > in /proc/PID/task/TID/maps and then give an overview of the entire mm > as it were, in /proc/PID/maps. > > At the thread group level, all vmas that are used as stacks are marked > as such. At the thread level however, only the stack that the task in > question uses is marked as such and all others (including the main > stack) are marked as anonymous memory. Please flesh this description out with specific examples of the before-and-after contents of all the applicable procfs files. This way we can clearly see the proposed interface changes, which is the thing we care most about with such a patch. The patch itself has been utterly and hopelessly mangled by gmail. Please fix that up when resending (as a last resort: use a text/plain attachment). -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
