From owner-freebsd-stable@FreeBSD.ORG Tue Dec 20 17:49:35 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32466106564A; Tue, 20 Dec 2011 17:49:35 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id CE1AF8FC1D; Tue, 20 Dec 2011 17:49:34 +0000 (UTC) Received: by ghrr16 with SMTP id r16so1299428ghr.13 for ; Tue, 20 Dec 2011 09:49:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/yB2BKZx/6e36AtZPwdSVN0mHcul88PgARujT7POimQ=; b=hujXdmjrSPOU4ibOa7+/ZYCaTpt9K+r5ga7wRU1z5uSCEqodBlHipIO4gtDkaGnZcd cBakuzfX+TEjrpXlWbldrFssOG1Y7v8cy4K1h1jBJw7SUzIsjl8b3uG+MZ5rq7Cj9de/ cFm7J4P1Lc+r4pC+DyUHh/zrT0Nt+xIP06Rho= MIME-Version: 1.0 Received: by 10.101.174.17 with SMTP id b17mr1580451anp.62.1324402063368; Tue, 20 Dec 2011 09:27:43 -0800 (PST) Sender: artemb@gmail.com Received: by 10.147.52.27 with HTTP; Tue, 20 Dec 2011 09:27:43 -0800 (PST) In-Reply-To: <4EF0A3A7.80309@FreeBSD.org> References: <20111220080437.M63044@martymac.org> <4EF05F27.8030902@FreeBSD.org> <20111220134716.M62917@martymac.org> <20111220142740.M29405@martymac.org> <4EF0A3A7.80309@FreeBSD.org> Date: Tue, 20 Dec 2011 09:27:43 -0800 X-Google-Sender-Auth: WCmHePoeZAU9Qc9DnSZjgiU4TDo Message-ID: From: Artem Belevich To: Ganael LAPLANCHE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Tijl Coosemans , freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: Using mmap(2) with a hint address X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 17:49:35 -0000 Hi, On Tue, Dec 20, 2011 at 7:03 AM, Andriy Gapon wrote: > on 20/12/2011 16:31 Ganael LAPLANCHE said the following: >> On Tue, 20 Dec 2011 15:02:01 +0100 (CET), Ganael LAPLANCHE wrote >> >>> But there is still something I don't understand : on the Linux >>> machine where I ran my test program, the current RLIMIT_DATA >>> is set to 0xffffffff/0xffffffff and I can manage to mmap at >>> address 0x20000000. If I set the same limit on FreeBSD, I >>> won't get the mapping at 0x20000000. So, there *is* a >>> difference of behaviour between the two systems, but I don't >>> understand why. >> >> Well, in fact, two things remain not very clear for me : >> >> - Why are mmap()s performed *after* data segment ? >> =A0 =3D> It seems they can go within, on GNU/Linux and NetBSD. >> >> - Why do we have such a default value for datasize (8.2, amd64) : >> >> $ limits >> Resource limits (current): >> =A0 cputime =A0 =A0 =A0 =A0 =A0 =A0 =A0infinity secs >> =A0 filesize =A0 =A0 =A0 =A0 =A0 =A0 infinity kB >> =A0 datasize =A0 =A0 =A0 =A0 =A0 =A0 33554432 kB >> >> this is HUGE ! > > Just a guess - this might be some sort of optimization to keep virtual ad= dress > range of dynamic allocations untouched by unrelated mmap calls. =A0Not su= re if > that's so and how useful could that be. Something like that. In the past heap allocator used to get memory from system via sbrk(). It still may do so, if you set MALLOC_OPTIONS=3DD. The problem is that sbrk() can't advance past an area used by something else (i.e. mmaped region) so kernel makes an effort to leave a lot of unused address space which sbrk() may claim later on. These days malloc() by default uses mmap, so if you don't force it to use sbrk() you can probably lower MAXDSIZE and let kernel use most of address space for hinted mmaps. That said, unless you use MAP_FIXED, malloc is not guaranteed to pay attention to hints and the app must be able to deal with that. FreeBSD kernel behavior is just one possible scenario that may affect mmap behavior. Behavior may also change between architectures, or due to preceeding mmaps (think of dynamic linker mapping in shared libraries). If an application relies on hints having effect without MAP_FIXED, it's the app that needs fixing, IMHO. --Artem > svn log / svn annotate of the file may reveal more details. > > -- > Andriy Gapon > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"