[lkml]   [2003]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: CLONE_THREAD with old (glibc 2.2.5) linuxthreads
On Fri, Feb 21, 2003 at 05:05:40PM -0800, Dave Pifke wrote:
> I'm attempting to add ps-like code to an application, and am running into
> a problem calculating the memory usage of multithreaded processes. The
> memory usage numbers in /proc/PID/statm don't give any indication as to
> whether or not the process shares its VM with another, thus a
> multithreaded application appears to be using (actual usage * number of
> threads).
> It looks like this could be easilly solved by looking at Tgid in
> /proc/PID/status and calculating memory usage per-thread-group instead of
> per-process. The problem, however, is that glibc 2.2.5 does not set
> CLONE_THREAD and so Tgid == Pid in every case.
> Would it break anything if I patch my glibc to set this flag? Is
> task_struct->tgid just informational in 2.4, or does it modify the
> behavior of the task somehow?

Don't even try it. CLONE_THREAD changs the semantics for signal

> Or, is there perhaps another way to see if CLONE_VM was set when the
> process was cloned? (Thus avoiding the need to change anything in glibc.)

There's no good way. Once you have the process tree you can make
pretty good guesses though; the hierarchy of LinuxThreads is quite
distinctive (first -> manager -> all children). It might be nice to
export the clone flags in proc.

Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:33    [W:0.030 / U:0.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site