Re: Virtual memory consumption (both user and kernel) in modern CURRENT

From: Dmitry Pryanishnikov <dmitry_at_atlantis.dp.ua>
Date: Fri, 17 Feb 2006 10:23:41 +0200 (EET)
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-RIPE
Received 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