From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 29 19:47:54 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BFFB106564A for ; Mon, 29 Dec 2008 19:47:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 73EFB8FC13 for ; Mon, 29 Dec 2008 19:47:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id D9F9B46B17; Mon, 29 Dec 2008 14:47:53 -0500 (EST) Date: Mon, 29 Dec 2008 19:47:53 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Dan Nelson In-Reply-To: <20081229154544.GB21654@dan.emsphone.com> Message-ID: References: <49585C75.80203@rawbw.com> <20081229154544.GB21654@dan.emsphone.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Yuri , freebsd-hackers@freebsd.org Subject: Re: How process size is calculated? Is it always based on the current highest available address in memory space? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2008 19:47:54 -0000 On Mon, 29 Dec 2008, Dan Nelson wrote: > In the last episode (Dec 28), Yuri said: >> malloc(3) can be controlled by MALLOC_OPTIONS to use mmap-based allocation >> as opposed to sbrk-based allocation. But allocations/deallocations with >> mmaps can eventually lead to non-continuously mmapped memory (having some >> non-mmapped gaps). >> >> Are these gaps excluded from the process size or size is always linked to >> the current highest available address in memory space? > > It looks like only mapped memory is counted in process size. The test > program below shows that the reported size goes down, even if a memory range > inbetween two others is unmapped: You can use procstat(8), or on older versions of FreeBSD procfs, to explore the layout of process memory, which may also lend some insight to what's going on. Robert N M Watson Computer Laboratory University of Cambridge > > $ ./mmap > Before mmap: > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 1000 48058 62165 0 8 0 1928 824 wait S+ ph 0:00.01 ./mmap > mmap 64MB A=0x28280000 > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 1000 48058 62165 0 8 0 67464 824 wait S+ ph 0:00.01 ./mmap > mmap 64MB B=0x2c280000 > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 1000 48058 62165 0 8 0 133000 824 wait S+ ph 0:00.01 ./mmap > mmap 64MB C=0x30280000 > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 1000 48058 62165 0 8 0 198536 824 wait S+ ph 0:00.01 ./mmap > munmap B > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 1000 48058 62165 0 8 0 133000 824 wait S+ ph 0:00.01 ./mmap > > > #include > #include > #include > #include > > int main(void) > { > char *cmd; > void *a, *b, *c; > asprintf(&cmd, "ps axlp %d", getpid()); > printf("Before mmap:\n"); > system(cmd); > a = mmap(NULL, 64 * 1024 * 1024, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); > printf("mmap 64MB A=%p\n", a); > system(cmd); > b = mmap(NULL, 64 * 1024 * 1024, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); > printf("mmap 64MB B=%p\n", b); > system(cmd); > c = mmap(NULL, 64 * 1024 * 1024, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); > printf("mmap 64MB C=%p\n", c); > system(cmd); > printf("munmap B\n"); > munmap(b, 64 * 1024 * 1024); > system(cmd); > return 0; > } > > > -- > Dan Nelson > dnelson@allantgroup.com > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >