Re: Trouble with recent auto-tuning changes

On Sun, Jan 27, 2013 at 12:11 PM, Ian Lepore <ian_at_freebsd.org> wrote:

> I ran into a panic while attempting to un-tar a large file on a
> DreamPlug (arm-based system) running -current.  The source and dest of
> the un-tar is the root filesystem on sdcard, and I get this:
>
> panic: kmem_malloc(4096): kmem_map too small: 12582912 total allocated
>
> Just before the panic I see the tar process get hung in a "nokva" wait.
> 12582912 is the value of VM_KMEM_SIZE from arm/include/vmparam.h.
>
> In r245575 the init order for mbuf limits was changed from
> SI_SUB_TUNABLES to SI_SUB_KMEM so that mbuf limits could be based on the
> results of sizing kernel memory.  Unfortunately, the process of sizing
> kernel memory relies on the mbuf limits; in kmeminit():
>
>         vm_kmem_size = VM_KMEM_SIZE + nmbclusters * PAGE_SIZE;
>
> Since r245575, nmbclusters is zero when this line of code runs.  If I
> manually plugin "32768" (the number tunable_mbinit() comes up with for
> this platform) in that line, the panic stops happening.
>
> So we've got two problems here... one is the circular dependency in
> calculating the mbuf limits.  The other is the fact that some
> non-trivial amount of kernel memory we're allowing for mbufs is actually
> being used for other things.  That is, if my system was actually using
> all the mbufs that tunable_mbinit() allowed for, then this panic while
> untarring a huge file would still have happened.
>
>
All of this is factually correct.  However, it's a red herring.  The real
problem is that arm, unlike every other architecture in the tree, does not
enable auto-sizing of the kmem map based on the physical memory size.
Specifically, you'll find VM_KMEM_SIZE_SCALE defined in
"arch"/include/vmparam.h on every other architecture, just not on arm.
This auto-sizing overrides the value of VM_KMEM_SIZE.



> I arrive at the latter conclusion based on the fact that this panic
> happens even if no network interfaces (other than lo0) are configured.
> That is, nmbclusters == 0 is a reasonable approximation of my need for
> network mbufs.  So something in the system needs to be taken into
> account when sizing kernel memory to allow for whatever it is about
> untarring a huge file that eats kernel memory (buffer cache?).
>
> I can easily reproduce this if you need me to gather any specific info.
>
> -- Ian
>
>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>