Date: Sat, 12 Jan 2013 14:45:45 -0500 From: Alfred Perlstein <bright@mu.org> To: Adrian Chadd <adrian@freebsd.org> Cc: src-committers@freebsd.org, Andre Oppermann <andre@freebsd.org>, Alan Cox <alc@rice.edu>, "Jayachandran C." <jchandra@freebsd.org>, svn-src-all@freebsd.org, Oleksandr Tymoshenko <gonzo@bluezbox.com>, freebsd-arch@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r243631 - in head/sys: kern sys Message-ID: <50F1BD69.4060104@mu.org> In-Reply-To: <CAJ-VmonLoL4E3UsNwx87p2FuHXTbJe7wFs9hBn5Zmr7TTQOSkg@mail.gmail.com> References: <201211272119.qARLJxXV061083@svn.freebsd.org> <ABB3E29B-91F3-4C25-8FAB-869BBD7459E1@bluezbox.com> <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> <CA%2B7sy7CkdoyScOEDEXWuwJxjCS5zTcC8_fu9isCeTFxT8opNJQ@mail.gmail.com> <50F04FE5.7010406@rice.edu> <CA%2B7sy7D=ZjTLirGW3BVGcAu0h8-dWpib%2BYziUjEqegOL9J4adw@mail.gmail.com> <CAJ-VmonLoL4E3UsNwx87p2FuHXTbJe7wFs9hBn5Zmr7TTQOSkg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. <jchandra@freebsd.org> wrote: >> On Fri, Jan 11, 2013 at 11:16 PM, Alan Cox <alc@rice.edu> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50F1BD69.4060104>