Hello! On Thu, 16 Feb 2006, Kris Kennaway wrote: >> Without putchar() call my program's virtual address space isn't so big: >> >> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND >> 52126 root 1 127 0 1244K 440K RUN 0:31 43.97% a.out >> >> But with putchar() it gives us >> >> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND >> 58959 root 1 130 0 50100K 632K RUN 0:03 47.19% a.out >> >> What't the reason of so terrible virtual memory consumption? I don't believe >> that just plain stdio buffering requires 50 Mbytes (!) of virtual address >> space. > > Note that only 200K of extra memory is used. Using 50MB of virtual Yes, I'm talking about virtual address space, not about resident set size. > address space is not going to cause any problems unless the pages are > touched, which as you can see from the resident size, they aren't. 1) Doesn't every page of the user virtual address space (even not being in RSS) have some associated descriptive information in KVA? Note my 2nd and 3rd questions: I'm running into a "kmem_map too small: 82014208 total allocated" panic on 256Mb box by _just_ issuing cd /usr/ports/editors/openoffice.org-2.0 NOCLEANDEPENDS=yes make extract clean Isn't that a shame? I'm trying to understand _what_ eats a lot of KVA. Can it be page descriptors for user processes, each of them has a huge VA overhead now? 2) These "dummy" Mbytes of VA make troubleshooting and debugging really difficult. Now it's hard to see actual memory leaks, they are masked by the dummy VA allocations. Huge size of core files is also a negative impact. My main question is: can we avoid allocating 50Mb for "Hello, world!"-type program? If it's just plain bug in new malloc, it should be corrected. If this huge allocation is absolutely necessary, one should at least have a choice (maybe, link-time option) which memory allocator to use, and don't link plain /bin/sh against virtual memory hungry allocator. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry_at_atlantis.dp.ua nic-hdl: LYNX-RIPEReceived on Fri Feb 17 2006 - 07:23:48 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:52 UTC