From owner-freebsd-arch@FreeBSD.ORG Sat Dec 8 20:54:06 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83977C8F for ; Sat, 8 Dec 2012 20:54:06 +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 DA8E68FC0C for ; Sat, 8 Dec 2012 20:54:05 +0000 (UTC) Received: (qmail 60427 invoked from network); 8 Dec 2012 22:23:40 -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 ; 8 Dec 2012 22:23:40 -0000 Message-ID: <50C3A8E4.3000401@freebsd.org> Date: Sat, 08 Dec 2012 21:53:56 +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: Adrian Chadd Subject: Re: svn commit: r243594 - head/sys/netinet References: <201211270304.qAR34PfD056691@svn.freebsd.org> <50B53ABC.1010304@freebsd.org> <50B57F46.1060207@mu.org> <50C205DC.1040701@freebsd.org> <50C23B5E.3020509@freebsd.org> <50C26BF9.1050106@mu.org> <50C278B0.3040107@mu.org> <52564974-563C-499F-9860-ADACA0DD22CE@bsdimp.com> <50C2839B.30709@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alfred Perlstein , Alfred Perlstein , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 20:54:06 -0000 On 08.12.2012 07:33, Adrian Chadd wrote: > I suggest something with some numbers/figures that we can look at and plot. > > Specifically: > > * Let's map out what the inputs are (eg total memory, total VM space) > * Let's map out what the outputs are (eg UMA zone sizing, total mbufs > allowed, etc) > * Let's plot what the current, pre-latest-fiddling-in-current code does; > * Let's plot what you and Andre think it should be, and then we can > see how that works on the RAM constrained platforms; > * Let's have a bit of a chat about it. I think there are a couple of things being mixed up here. One is the ARM problem. This is related to maxusers. See further down. Two is setting limits for a maximal amount of mbufs in the system. This is 50% of real memory or kmem, whichever is lower, by default. Previously certain types where not limited and others were limited based on maxusers. This was overestimating on small memory configs and severely underestimating on large memory configs. Three is setting limits for maxfiles/maxsockets. This is now scaled according to memory as well. Previously it was derived from maxusers as well with the same trouble as in point two. Four is deciding on an optimal hash table size for TCP control blocks. The number of concurrent tcp connections is limited by maxsockets. The point of contention here is with which fraction of the maxsockets value the hash table should end up. The hash table chains entries when a hash bucket collision happens. So no limit there. It all ends up with a time vs. space tradeoff in the hash table. Any of the proposals being discussed is better than what we had before (fixed 512 hash buckets). > Until Oleksandr and Andre figure out exactly why Andre's tweaks have > broken memory allocation on ARM (and until he and I stare at MIPS a > bit more, especially on the RAM constrained AP platforms) we can only > guess what the underlying reasons for his issues are. Oleksandr thinks > "fragmentation", but we just don't know. So that's worth figuring out. There seems to be a problem with sf_buf kmap allocation at least on ARM which results in the kernel becoming unable to allocate a stack for threads and processes. The sf_buf kmap is derived from maxusers which is derived from phypages. Why exactly a kmap allocation of 27MB hoses the whole kernel is not yet understood. > You don't have to wait. There's plenty to do. Heck, I wonder what > platform Oleksandr is using where an ARM board has 1GB of RAM. Maybe > we should get some more of those for people to play with. Your favorite smartphone likely has 512MB-1GB of RAM. -- Andre