This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: proc memory statistics tapset
Hi Josh,
On Tue, 2009-10-06 at 16:39 -0700, Josh Stone wrote:
> On 10/06/2009 10:25 AM, Mark Wielaard wrote:
> >> "Task isn't coopted
> >> by a kernel thread" doesn't make sense to me either -- kernel threads
> >> have their own current task_struct, represented by that KTHREAD flag.
> >
> > I am not 100% sure that is correct. Task flags is set the PT_KTHREAD in
> > INIT_TASK() before it is fully created. I even extended that check to:
> > current->flags & (_STP_PF_KTHREAD | PF_EXITING | PF_STARTING)
> > just to be fully paranoid we never query some task-mm struct that isn't
> > setup right. Feel free to proof me wrong in being that paranoid :)
>
> INIT_TASK() is not a generic initializer -- it's only used to create the
> specific "init_task". Everybody else is copied from their parent in
> copy_process().
Aha, thanks, I misread. But I think the check is still the right one.
> I think your paranoia is ok to make sure there's a meaningful mm. I was
> more interested in what you meant by "coopted by" -- in which cases
> could a kernel thread pop in without changing current to itself?
Normally kernel threads don't have an associated mm struct. But they can
"coopt" one from a user thread (for example when doing aio on behave of
some process), then current->mm != NULL, but current->flags still has
PT_KTHREAD. IMHO we should not report such mm sizes.
> An interrupt handler could be considered such a case, but I don't think
> those should be filtered out. A timer.profile fires in softIRQ context,
> but it's probably reasonable to profile your memory usage this way.
> Even our own trap handlers could be seen as "coopting" the process.
Yes, we should catch normal "interrupted" user tasks. With timer.profile
you get output like: stap -e 'probe timer.profile { if (pid() != 0)
printf("%s (%d)\n\t%s\n", execname(), tid(), proc_mem_string()) }'
firefox (31452)
size: 787M, rss: 144M, shr: 25.8M, txt: 84.0K, data: 283M
gnome-terminal (4017)
size: 287M, rss: 21.9M, shr: 9.45M, txt: 272K, data: 22.5M
Xorg (2745)
size: 479M, rss: 71.0M, shr: 12.1M, txt: 1.70M, data: 71.5M
Xorg (2745)
size: 479M, rss: 71.0M, shr: 12.1M, txt: 1.70M, data: 71.5M
Xorg (2745)
size: 479M, rss: 71.0M, shr: 12.1M, txt: 1.70M, data: 71.5M
Xorg (2745)
size: 479M, rss: 71.0M, shr: 12.1M, txt: 1.70M, data: 71.5M
Xorg (2745)
size: 479M, rss: 71.0M, shr: 12.1M, txt: 1.70M, data: 71.5M
systemtap/5 (1699)
size: 0, rss: 0, shr: 0, txt: 0, data: 0
ksoftirqd/5 (19)
size: 0, rss: 0, shr: 0, txt: 0, data: 0
ksoftirqd/5 (19)
size: 0, rss: 0, shr: 0, txt: 0, data: 0
gnome-terminal (4017)
size: 287M, rss: 21.9M, shr: 9.45M, txt: 272K, data: 22.5M
Xorg (2745)
size: 479M, rss: 71.0M, shr: 12.1M, txt: 1.70M, data: 71.5M
Xorg (2745)
size: 479M, rss: 71.0M, shr: 12.1M, txt: 1.70M, data: 71.5M
gnome-terminal (4017)
size: 287M, rss: 21.9M, shr: 9.45M, txt: 272K, data: 22.5M
Cheers,
Mark