Date: Fri, 17 Feb 2006 10:23:41 +0200 (EET) From: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua> To: Kris Kennaway <kris@obsecurity.org> Cc: freebsd-current@freebsd.org, David Xu <davidxu@freebsd.org> Subject: Re: Virtual memory consumption (both user and kernel) in modern CURRENT Message-ID: <20060217093631.J79078@atlantis.atlantis.dp.ua> In-Reply-To: <20060217013427.GB31540@xor.obsecurity.org> References: <20060215024339.N22450@atlantis.atlantis.dp.ua> <43F29BF5.4060300@freebsd.org> <20060216140725.T23429@atlantis.atlantis.dp.ua> <20060217013427.GB31540@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@atlantis.dp.ua
nic-hdl: LYNX-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060217093631.J79078>