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. <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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Reply via email to