From owner-freebsd-current@FreeBSD.ORG Fri Mar 8 12:58:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 68C5D186 for ; Fri, 8 Mar 2013 12:58:49 +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 BBEC5F4B for ; Fri, 8 Mar 2013 12:58:48 +0000 (UTC) Received: (qmail 70224 invoked from network); 8 Mar 2013 14:12:05 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Mar 2013 14:12:05 -0000 Message-ID: <5139E07E.4040704@freebsd.org> Date: Fri, 08 Mar 2013 13:58:38 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Cleanup and untangling of kernel VM initialization References: <510BC24D.2090406@freebsd.org> <510BF6E0.8070007@rice.edu> <5138C877.9060808@freebsd.org> <20130308091634.GM3794@kib.kiev.ua> In-Reply-To: <20130308091634.GM3794@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-current@freebsd.org, Alan Cox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Fri, 08 Mar 2013 12:58:49 -0000 On 08.03.2013 10:16, Konstantin Belousov wrote: > On Thu, Mar 07, 2013 at 06:03:51PM +0100, Andre Oppermann wrote: >> pager_map: is used for pager IO to a storage media (disk). Not >> pageable. Calculation: MAXPHYS * min(max(nbuf/4, 16), 256). > > It is more versatile. The space is used for pbufs, and pbufs currently > also serve for physio, for the clustering, for aio needs. Good to know. Isn't the ceiling of MAXPHYS * 256 a bit tight then? >> memguard_map: is a special debugging submap substituting parts of >> kmem_map. Normally not used. >> >> There is some competition between these maps for physical memory. One >> has to be careful to find a total balance among them wrt. static and >> dynamic physical memory use. > > They mostly compete for KVA, not for the physical memory. Indeed. On 32bit architectures KVA usually is 1GB which is rather limited. >> Within the submaps, especially the kmem_map, we have a number of >> dynamic UMA suballocators where we have to put a ceiling on their >> total memory usage to prevent them to consume all physical *and/or* >> kmem_map virtual memory. This is done with UMA zone limits. > > Note that architectures with the direct maps do not use kmem_map for > the small allocations. The uma_small_alloc() utilizes the direct map > for VA of the new page. kmem_map is needed when allocation is multi-page > sized, to provide the continuous virtual mapping. Can you please explain the direct map some more? I haven't found any good documentation or comments on it. >> It could be that some of the kernel_map submaps are no longer >> necessary and their purpose could simply be emulated by using an >> appropriately limited UMA zone. For example the exec_map is very small >> and only used for the exec arguments. Putting this into pageable >> memory isn't very useful anymore. > > I disagree. Having the strings copied on execve() pageable is good, > the default size of around 260KB max for the strings is quite a > load on the allocator. Oops. You're right. I didn't notice how big ARG_MAX can be. -- Andre