From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 10:29:31 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B01D335 for ; Mon, 1 Jun 2015 10:29:31 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B03411841 for ; Mon, 1 Jun 2015 10:29:30 +0000 (UTC) (envelope-from zec@fer.hr) Received: from x23 (161.53.63.210) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 1 Jun 2015 12:29:27 +0200 Date: Mon, 1 Jun 2015 12:30:07 +0200 From: Marko Zec To: Luigi Rizzo CC: FreeBSD Current , Giuseppe Lettieri , Stefano Garzarella , Vincenzo Maffione Subject: Re: superpages in FreeBSD (netmap related) ? Message-ID: <20150601123007.40def520@x23> In-Reply-To: References: <20150601115411.1f95bd00@x23> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [161.53.63.210] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 10:29:31 -0000 On Mon, 1 Jun 2015 12:11:12 +0200 Luigi Rizzo wrote: > On Monday, June 1, 2015, Marko Zec wrote: > > > On Mon, 1 Jun 2015 11:34:00 +0200 > > Luigi Rizzo > wrote: > > > > > Hi, > > > i was wondering how we can improve the netmap memory allocator > > > to make use of 2M pages (through the page promotion trick). > > > > > > in netmap, when we allocate packet buffers, > > > we issue requests for 4k blocks to contigmalloc(), > > > and i have no idea if there is a way to improve the > > > chance that the memory is mapped to 2M pages ? > > > > In my (previous life) experience, when requested large enough > > blocks, malloc() did a good job at automatically promoting those to > > superpages, and in my applications this behavior was 100% > > consistent, at least on amd64. After the block is allocated one > > can check whether it is superpage-mapped: > > > > pmap_t pmap = vmspace_pmap(curthread->td_proc->p_vmspace); > > > > if (pmap_mincore(pmap, (vm_offset_t) addr) & MINCORE_SUPER) > > /* you're good */ > > else > > /* bad luck */ > > > Thanks. Do you know if there is any way to run some equivalente test > from user space ? Sure, here's a quickie: #include #include #include #include int main(int argc, char **argv) { size_t size, flags, i, super = 0, ordinary = 0; void *addr; char *vec; if (argc != 2) return (0); size = atoi(argv[1]); addr = malloc(size); vec = malloc(size / 4096); memset(addr, 0, size); flags = mincore(addr, size, vec); printf("addr %p len %d:\n", addr, size); for (i = 0; i <= size / 4096; i++) if (vec[i] & MINCORE_SUPER) super++; else ordinary++; printf("%d 4K blocks super-mapped, %d ordinary 4K pages\n", super, ordinary); return (0); } x23% ./a.out 1000000 addr 0x801006000 len 1000000: 0 4K blocks super-mapped, 245 ordinary 4K pages x23% ./a.out 10000000 addr 0x801000000 len 10000000: 2048 4K blocks super-mapped, 394 ordinary 4K pages x23% ./a.out 100000000000 addr 0x801000000 len 1215752192: 296448 4K blocks super-mapped, 367 ordinary 4K pages The key is that the pages must be touched to be considered for merging in superpages! Marko > Cheers > Luigi > > > > OTOH I'm not aware of any mechanisms for forcing superpage > > allocations at malloc() time. > > > > Marko > > > >