From owner-svn-src-all@FreeBSD.ORG Fri Feb 1 19:58:57 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C75D1E95 for ; Fri, 1 Feb 2013 19:58:57 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3DB73C23 for ; Fri, 1 Feb 2013 19:58:56 +0000 (UTC) Received: (qmail 45507 invoked from network); 1 Feb 2013 21:18:32 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 1 Feb 2013 21:18:32 -0000 Message-ID: <510C1E7A.2090509@freebsd.org> Date: Fri, 01 Feb 2013 20:58:50 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Alan Cox Subject: Re: svn commit: r246204 - head/sys/arm/include References: <201302011026.r11AQVL9068427@svn.freebsd.org> <510C00CB.8000409@rice.edu> In-Reply-To: <510C00CB.8000409@rice.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 19:58:57 -0000 On 01.02.2013 18:52, Alan Cox wrote: > On 02/01/2013 04:26, Andre Oppermann wrote: >> Author: andre >> Date: Fri Feb 1 10:26:31 2013 >> New Revision: 246204 >> URL: http://svnweb.freebsd.org/changeset/base/246204 >> >> Log: >> Add VM_KMEM_SIZE_SCALE parameter set to 2 (50%) for all ARM platforms. >> >> VM_KMEM_SIZE_SCALE specifies which fraction of the available physical >> memory, after deduction of the kernel itself and other early statically >> allocated memory, can be used for the kmem_map. The kmem_map provides >> for all UMA/malloc allocations in KVM space. >> > > Not always. Off the top of my head, two things immediately come to > mind: 9KB and 16KB jumbo frames come from the kernel map, because we > allocate physically contiguous memory for them, and some swap metadata > also comes from the kernel map. I'd love to remove jumbo clusters that are larger than PAGE_SIZE. The hard need of s/g challenged network cards is gone. All contemporary networks can deliver a jumbo frame into a PAGE_SIZE'd mbuf cluster chains. Some can even split off the headers into a separate mbuf. A quick search for kernel_map allocations didn't show many other direct users of the kernel_map. The XEN net and blk backends do make use of it. Other users have their own submaps: exec_map, pipe_map, buffer_map and pager_map. > Yes, all "ordinary" heap allocations come from the kmem map, but a > number of things that are special for one reason or another don't. -- Andre