From owner-freebsd-arch@FreeBSD.ORG Sat Jan 12 19:45:52 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4CCAAADB; Sat, 12 Jan 2013 19:45:52 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1EE6C729; Sat, 12 Jan 2013 19:45:51 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (unknown [207.238.187.242]) by elvis.mu.org (Postfix) with ESMTPSA id 9026A1A3C55; Sat, 12 Jan 2013 11:45:46 -0800 (PST) Message-ID: <50F1BD69.4060104@mu.org> Date: Sat, 12 Jan 2013 14:45:45 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Adrian Chadd 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> <50D03E83.8060908@rice.edu> <50DD081E.8000409@bluezbox.com> <50EB1841.5030006@bluezbox.com> <50EB22D2.6090103@rice.edu> <50EB415F.8020405@freebsd.org> <50F04FE5.7010406@rice.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: src-committers@freebsd.org, Andre Oppermann , Alan Cox , "Jayachandran C." , svn-src-all@freebsd.org, Oleksandr Tymoshenko , freebsd-arch@freebsd.org, svn-src-head@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, 12 Jan 2013 19:45:52 -0000 On 1/12/13 11:56 AM, Adrian Chadd wrote: > Hi, > > I think this outlines a larger scale problem here, which is that way, > way too many things are relying on maxfiles here and it wasn't > properly reviewed or thought out before it made it into the tree. > > So, can we either: > > * review _all_ the places maxfiles is being used, and finally fix those; > * .. or revert this work until said review and fixup is done? > > This is the kind of thing that we should just not mess up at this point.. I'm not sure if regressing to the waterfall method of development is a good idea at this point. I see a light at the end of the tunnel and we to continue to just handle these minor corner cases as we progress. If we move to a model where a minor bug is grounds to completely remove helpful code then nothing will ever get done. -Alfred > Thanks, > > > > Adrian > > On 12 January 2013 07:46, Jayachandran C. wrote: >> On Fri, Jan 11, 2013 at 11:16 PM, Alan Cox wrote: >>> On 01/11/2013 05:38, Jayachandran C. wrote: >> [...] >>>> I see an issue with commit on MIPS XLP platform as well. >>>> >>>> With 16 GB physical memory, the ncallout is calculated to be 538881 >>>> (since it is based on maxfiles - which is now based on the physical >>>> memory). Due to this, the callwheel allocation per cpu is 16MB >>>> (callwheelsize is 1MB). And on a 32 CPU machine, the total allocation >>>> for callouts comes to 32*16MB = 512MB. >>>> >>>> I have worked around this issue for now by increasing VM_KMEM_SIZE_MAX >>>> (which is 200MB now) - but I think a better fix is needed for this. >>>> >>> MIPS should use a definition for VM_KMEM_SIZE_MAX that scales with the >>> kernel address space size, like amd64, i386, and sparc64, and not a >>> fixed number. I think that the following should work for both 32- and >>> 64-bit processors: >>> >>> Index: mips/include/vmparam.h >>> =================================================================== >>> --- mips/include/vmparam.h (revision 245229) >>> +++ mips/include/vmparam.h (working copy) >>> @@ -130,10 +130,11 @@ >>> #endif >>> >>> /* >>> - * Ceiling on amount of kmem_map kva space. >>> + * Ceiling on the amount of kmem_map KVA space: 40% of the entire KVA >>> space. >>> */ >>> #ifndef VM_KMEM_SIZE_MAX >>> -#define VM_KMEM_SIZE_MAX (200 * 1024 * 1024) >>> +#define VM_KMEM_SIZE_MAX ((VM_MAX_KERNEL_ADDRESS - \ >>> + VM_MIN_KERNEL_ADDRESS + 1) * 2 / 5) >>> #endif >>> >>> /* initial pagein size of beginning of executable file */ >> This fix is needed, can you please check it in? I have tested it for >> 32 and 64 bit. >> >> But the second part of the problem - allocating 512MB out of 16GB at >> boot-time for callouts - might need a fix as well. >> >> Thanks, >> JC.