This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]