svn commit: r269964 - head/sys/kern

[John-Mark Gurney]

Xin Li wrote this message on Sat, Sep 13, 2014 at 14:05 +0800:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 9/13/14 1:22 PM, John-Mark Gurney wrote:
> > Xin Li wrote this message on Sat, Sep 13, 2014 at 12:23 +0800:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
> >> 
> >> On 9/13/14 3:41 AM, Adrian Chadd wrote:
> >>> Hi guys,
> >>> 
> >>> Both r269963 and r269964 have broken the MIPS platforms with 
> >>> smaller amounts of RAM (< 64MB.)
> >>> 
> >>> Sean noticed it and filed a bug:
> >>> 
> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193465
> >>> 
> >>> Can we please figure out what changed? Otherwise I'm going to 
> >>> revert these two changes until we figure out what happened.
> >> 
> >> Could you please try if this would mitigate the issue?
> >> 
> >> Index: sys/kern/kern_malloc.c 
> >> ===================================================================
> >>
> >> 
> - - --- sys/kern/kern_malloc.c      (revision 271494)
> >> +++ sys/kern/kern_malloc.c      (working copy) @@ -717,6 +717,8
> >> @@ kmeminit(void) * a given architecture. */ mem_size =
> >> vm_cnt.v_page_count; +       if (mem_size <= 32768) /* delphij
> >> XXX 128MB */ +               kmem_zmax = PAGE_SIZE;
> >> 
> >> if (vm_kmem_size_scale < 1) vm_kmem_size_scale =
> >> VM_KMEM_SIZE_SCALE;
> >> 
> > 
> > Has more research been done on this?  My 64MB AVILA board boots
> > fine, and ath attaches fine...
> 
> It's theoretically possible that my change brings a regression for
> small system, as the larger allocation units now "caches" the
> allocation instead of returning them immediately.  Sean also confirms
> that reverting the two changes only would fix the issue, so I think we
> should use some autotune here.

I agree that it could possibly bring a regression for small memory
systems, but I'm not seeing that w/ mine...  and it looks like we have
zone draining in the case of low memory, though it looks like we don't
have a "target" for how much memory to free, nor do we order which zones
we should free from (like remembering where we stopped, so we don't
flush all memory, or target zones/buckets)...

I'm also concerned that your patch prevents people from using a larger
max if they'd like by setting a tunable... Your patch just hard sets
it, preventing the tunable to doing anything useful on these smaller
systems, so if someone wants the additional zones, they'd need to
modify the source...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."