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."
_______________________________________________
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"
