From owner-svn-src-head@FreeBSD.ORG Tue Dec 18 09:27:28 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7707CCAA for ; Tue, 18 Dec 2012 09:27:28 +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 D02508FC15 for ; Tue, 18 Dec 2012 09:27:27 +0000 (UTC) Received: (qmail 22830 invoked from network); 18 Dec 2012 10:55:13 -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 ; 18 Dec 2012 10:55:13 -0000 Message-ID: <50D036F8.1000406@freebsd.org> Date: Tue, 18 Dec 2012 10:27:20 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Oleksandr Tymoshenko Subject: Re: svn commit: r243631 - in head/sys: kern sys References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50C1BC90.90106@freebsd.org> <50C25A27.4060007@bluezbox.com> <50C26331.6030504@freebsd.org> <50C26AE9.4020600@bluezbox.com> <50C3A3D3.9000804@freebsd.org> <50C3AF72.4010902@rice.edu> <330405A1-312A-45A5-BB86-4969478D8BBD@bluezbox.com> In-Reply-To: <330405A1-312A-45A5-BB86-4969478D8BBD@bluezbox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Alan Cox X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 09:27:28 -0000 On 18.12.2012 06:40, Oleksandr Tymoshenko wrote: > > On 2012-12-08, at 1:21 PM, Alan Cox wrote: > >> On 12/08/2012 14:32, Andre Oppermann wrote: >>>> > > .. skipped .. > >>> >>> The trouble seems to come from NSFBUFS which is (512 + maxusers * 16) >>> resulting in a kernel map of (512 + 400 * 16) * PAGE_SIZE = 27MB. This >>> seem to be pushing it with the smaller ARM kmap layout. >>> >>> Does it boot and run when you set the tunable kern.ipc.nsfbufs=3500? >>> >>> ARM does have a direct map mode as well which doesn't require the >>> allocation >>> of sfbufs. I'm not sure which other problems that approach has. >>> >> >> >> Only a few (3?) platforms use it. It reduces the size of the user >> address space, and translation between physical addresses and direct map >> addresses is not computationally trivial as it is on other >> architectures, e.g., amd64, ia64. However, it does try to use large >> page mappings. >> >> >>> Hopefully alc@ (added to cc) can answer that and also why the kmap of >>> 27MB >>> manages to wrench the ARM kernel. >>> >> >> >> Arm does not define caps on either the buffer map size (param.h) or the >> kmem map size (vmparam.h). It would probably make sense to copy these >> definitions from i386. > > > Adding caps didn't help. I did some digging and found out that although address range > 0xc0000000 .. 0xffffffff is indeed valid for ARM in general actual KVA space varies for > each specific hardware platform. This "real" KVA is defined by > pair and ifI use them instead of > in init_param2 function my pandaboard successfully boots. Since former pair is used for defining > kernel_map boundaries I believe it should be used for auto tuning as well. OK. Thank you for debugging this on ARM. I'll adjust the auto-tuning code accordingly. -- Andre