Huge linux memory footprint (using pthreads).
Alexander Sirotkin
adds about 8mb to a memory footprint, which is kinda
weird.
The foolowing code
#include <pthread.h>
#include <stdlib.h>
void * func(void * in) {
getchar();
}
int main() {
pthread_t t[2];
pthread_create(t, NULL, func, NULL);
pthread_create(t+1, NULL, func, NULL);
getchar();
return 1;
}
gives 18 mb !!
root 1864 0.0 0.3 17896 368 pts/1 S 19:00 0:00 ./a.out
Removing one of the "pthread_create"s gives 10 mb
root 1910 0.0 0.3 9704 364 pts/1 S 19:03 0:00 ./a.out
Isn't it too much ? Am I missing something ?
Steven Rostedt
processes/threads:
rostedt 1253 0.5 0.1 5548 432 pts/0 S 12:39 0:00 ./a.out
rostedt 1254 0.0 0.1 5548 432 pts/0 S 12:39 0:00 ./a.out
rostedt 1255 0.0 0.1 5548 432 pts/0 S 12:39 0:00 ./a.out
rostedt 1256 0.0 0.1 5548 432 pts/0 S 12:39 0:00 ./a.out
All at 5 meg each. But they are sharing the memory and do not take up
20 megs. glibc is the culprit in the large size anyway.
$ cat /proc/1254/maps
08048000-08049000 r-xp 00000000 03:08 10383 /home/rostedt/c/a.out
08049000-0804a000 rw-p 00000000 03:08 10383 /home/rostedt/c/a.out
0804a000-0804c000 rwxp 00000000 00:00 0
40000000-40015000 r-xp 00000000 03:03 26573 /lib/ld-2.2.4.so
40015000-40016000 rw-p 00014000 03:03 26573 /lib/ld-2.2.4.so
40016000-40018000 rw-p 00000000 00:00 0
4002d000-4003c000 r-xp 00000000 03:03 26616 /lib/libpthread-0.9.so
4003c000-40044000 rw-p 0000e000 03:03 26616 /lib/libpthread-0.9.so
40044000-40170000 r-xp 00000000 03:03 32392 /lib/libc-2.2.4.so
40170000-40176000 rw-p 0012b000 03:03 32392 /lib/libc-2.2.4.so
40176000-4017a000 rw-p 00000000 00:00 0
bf400000-bf401000 ---p 00000000 00:00 0
bf401000-bf600000 rwxp 00001000 00:00 0
bf600000-bf601000 ---p 00000000 00:00 0
bf601000-bf800000 rwxp 00001000 00:00 0
bfffe000-c0000000 rwxp fffff000 00:00 0
4K for the executable, 4K for the data (both the min since 4k is the
page size). 8k for bss and heap. 8K for stack. Now that is not that
much, and most (even the libc part) is not in memory anyway.
-- Steve
Alexander Sirotkin
Steven Rostedt wrote:
> Which kernel are you using?
I was using 2.4.9, but it's not the target platform.
> On 2.4.18 I get 4 (why 4?)
Why 4 ? This is simple - 1 main thread, 2 threads created
with pthread_create and 1 posix management thread.
> rostedt 1256 0.0 0.1 5548 432 pts/0 S 12:39 0:00 ./a.out
Well, on your system it takes 5.5 mb, compared to 17 mb on mine.
Weird...
> 20 megs. glibc is the culprit in the large size anyway.
You are right, this huge memory footprint is probably
because of glibc, will try uclibc later today...
>
> 4K for the executable, 4K for the data (both the min since 4k is the
> page size). 8k for bss and heap. 8K for stack. Now that is not that
> much, and most (even the libc part) is not in memory anyway.
Yep. Data, bss, text and stack don't take too much memory, but VSZ is
still huge.
And yes, I know that most of this meory is not used and thus is not
really allocated by the kernel, but I was trying to get an impression of
how much physical memory my application needs.
>
> -- Steve
>
Steven Rostedt
> Steven Rostedt wrote:
> Why 4 ? This is simple - 1 main thread, 2 threads created
> with pthread_create and 1 posix management thread.
>
Thanks,
I didn't know about the posix management thread.
-- Steve
Kasper Dupont
>
> Steven Rostedt wrote:
>
>
> You are right, this huge memory footprint is probably
> because of glibc, will try uclibc later today...
Most of it is shared between most of the processes on the
system, so it is rarely a major problem.
--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaa...@daimi.au.dk
Hvem er fjenden i Aalborg?
Alexander Sirotkin
on how much physical memory my application really needs.
Alexander Sirotkin
David Schwartz
>
> Which kernel are you using? On 2.4.18 I get 4 (why 4?)
> processes/threads:
>
> rostedt 1253 0.5 0.1 5548 432 pts/0 S 12:39 0:00 ./a.out
> rostedt 1254 0.0 0.1 5548 432 pts/0 S 12:39 0:00 ./a.out
> rostedt 1255 0.0 0.1 5548 432 pts/0 S 12:39 0:00 ./a.out
> rostedt 1256 0.0 0.1 5548 432 pts/0 S 12:39 0:00 ./a.out
>
> All at 5 meg each. But they are sharing the memory and do not take up
> 20 megs. glibc is the culprit in the large size anyway.
Note that that's 5Mb of *VIRTUAL* memory. I doubt you really need to
conserve virtual memory.
DS
Steven Rostedt
>
> Note that that's 5Mb of *VIRTUAL* memory. I doubt you really need to
> conserve virtual memory.
>
My point is that 5Mb was used for a small program. Not that the 5Mb was
taking up too much VM. I have developed for small boards where memory
is tight and 5Mb are a lot for one small program. Although most of
it may be shared, but it still is a lot.
-- Steve
David Schwartz
> David Schwartz wrote:
> > Note that that's 5Mb of *VIRTUAL* memory. I doubt you really need to
> > conserve virtual memory.
> My point is that 5Mb was used for a small program. Not that the 5Mb was
> taking up too much VM.
5Mb of VIRTUAL memory is too much?
> I have developed for small boards where memory
> is tight and 5Mb are a lot for one small program.
Where physical memory is tight or where virtual memory is tight?
> Although most of
> it may be shared, but it still is a lot.
5Mb may be a lot of physical memory, but it is not a lot of virtual
memory.
DS
Blane Bramble
news:3E0EB50D...@webmaster.com...
> 5Mb may be a lot of physical memory, but it is not a lot of virtual
> memory.
>
If your board only has 8mb of memory, and no swap, 5Mb of virtual memory is
probably too much.
Blane.
Steven Rostedt
> If your board only has 8mb of memory, and no swap, 5Mb of virtual memory is
> probably too much.
>
Thank you, that was my point, and I don't think I explained it well.
-- Steve
Wolfgang Mües
> If your board only has 8mb of memory, and no swap, 5Mb of virtual memory
> is probably too much.
No.
Virtual Memory means nothing.
Only real Memory usage counts.
best regards
Wolfgang
David Schwartz
In general, that's nonsense. There is no special relationship between
virtual memory consumption and physical memory consumption.
In this particular case, that 5Mb of virtual memory will probably
ultimately translate into some level of physical memory usage. But
without measuring, it's impossible to say how much.
DS