From owner-freebsd-current@FreeBSD.ORG Fri Mar 8 18:42:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 42E18686; Fri, 8 Mar 2013 18:42:38 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) by mx1.freebsd.org (Postfix) with ESMTP id DADC7F09; Fri, 8 Mar 2013 18:42:37 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id r28CnKGi017780; Fri, 8 Mar 2013 12:42:31 -0600 Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by pp2.rice.edu with ESMTP id 1axwtu0er1-1; Fri, 08 Mar 2013 12:42:31 -0600 Received: from mh2.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh2.mail.rice.edu (Postfix) with ESMTP id 352265001C8; Fri, 8 Mar 2013 12:42:31 -0600 (CST) Received: from mh2.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh2.mail.rice.edu (Postfix) with ESMTP id 33E435001C4; Fri, 8 Mar 2013 12:42:31 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel Received: from mh2.mail.rice.edu ([127.0.0.1]) by mh2.mail.rice.edu (mh2.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id CVOBnZD-WOYo; Fri, 8 Mar 2013 12:42:31 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id A48445001BC; Fri, 8 Mar 2013 12:42:30 -0600 (CST) Message-ID: <513A3115.5060609@rice.edu> Date: Fri, 08 Mar 2013 12:42:29 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130127 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andre Oppermann 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> <5139E07E.4040704@freebsd.org> In-Reply-To: <5139E07E.4040704@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=5800 signatures=585085 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=3 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1111160001 definitions=main-1101130121 Cc: Konstantin Belousov , alc@freebsd.org, freebsd-current@freebsd.org 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 18:42:38 -0000 On 03/08/2013 06:58, Andre Oppermann wrote: > 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. > Take a look at a MIPS architecture manual. Some architectures, such as MIPS, provide an alternate mechanism for virtual-to-physical address translation for use by the OS. Typically, a range of virtual addresses are reserved for this mechanism, and accesses to virtual addresses within this range bypass the usual translation process involving TLBs and page tables. Often, but not always, this range covers the entire physical memory of the machine, and both the forward mapping from virtual to physical and the inverse mapping from physical to virtual are trivially computed. Sometimes we implement a direct map in software when none exists in hardware, for example, amd64. On amd64 we use large pages, either 2MB or 1GB, to simulate a hardware-supported direct map. Even though it is not directly supported by hardware, it is nonetheless a useful optimization because it can be used in preference to creating and destroying mappings on as needed basis. >>> 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. >