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.. Thanks, Adrian On 12 January 2013 07:46, Jayachandran C. <jchan...@freebsd.org> wrote: > On Fri, Jan 11, 2013 at 11:16 PM, Alan Cox <a...@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. _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
