Date: Mon, 10 Jun 2013 23:13:58 +0200 From: Olivier Houchard <cognet@ci0.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, Alan Cox <alc@rice.edu> Subject: Re: svn commit: r251586 - head/sys/arm/ti Message-ID: <20130610211358.GA55399@ci0.org> In-Reply-To: <20130610193736.GF3047@kib.kiev.ua> References: <201306092251.r59MpCmW006162@svn.freebsd.org> <20130610035547.GX3047@kib.kiev.ua> <20130610110847.GA46614@ci0.org> <51B6069C.6060704@rice.edu> <20130610193736.GF3047@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 10, 2013 at 10:37:36PM +0300, Konstantin Belousov wrote: > On Mon, Jun 10, 2013 at 12:02:20PM -0500, Alan Cox wrote: > > On 06/10/2013 06:08, Olivier Houchard wrote: > > > On Mon, Jun 10, 2013 at 06:55:47AM +0300, Konstantin Belousov wrote: > > >> On Sun, Jun 09, 2013 at 10:51:12PM +0000, Olivier Houchard wrote: > > >>> Author: cognet > > >>> Date: Sun Jun 9 22:51:11 2013 > > >>> New Revision: 251586 > > >>> URL: http://svnweb.freebsd.org/changeset/base/251586 > > >>> > > >>> Log: > > >>> Increase the maximum KVM available on TI chips. Not sure why we suddenly need > > >>> that much, but that lets me boot with 1GB of RAM. > > >> I suspect that the cause is the combination of limited KVA and > > >> lack of any limitation for the buffer map. I noted that ARM lacks > > >> VM_BCACHE_SIZE_MAX after a report from mav about similar (?) problem a > > >> day ago. > > >> > > >> In essence, the buffer map is allowed to take up to ~330MB when no > > >> upper limit from VM_BCACHE_SIZE_MAX is specified. > > > > > > Hi Konstantin, > > > > > > Thanks for the hint ! > > > It seems only i386 and sparc64 sets it, what would be a good value, 200M, as > > > it is on i386 ? > > > > > > > Since there are many arm platforms with less than 1 GB of kernel virtual > > address (KVA) space, VM_BCACHE_SIZE_MAX should be made to scale down > > from 200 MB with the available KVA space. See how VM_KMEM_SIZE_MAX is > > currently defined on arm. > > In fact, Ithink it does not make much sense to scale the buffer cache up. > It is mostly wasted space now. As I measured it, on typical load you > have only 10-20% of instantiated buffers mapped. > > Alexander Motin reported that he tested the equivalent of the following > change. With it committed, I think that r251586 could be reverted. > > diff --git a/sys/arm/include/param.h b/sys/arm/include/param.h > index 9ffb118..5c738c2 100644 > --- a/sys/arm/include/param.h > +++ b/sys/arm/include/param.h > @@ -128,6 +128,11 @@ > #define USPACE_SVC_STACK_BOTTOM (USPACE_SVC_STACK_TOP - 0x1000) > #define USPACE_UNDEF_STACK_TOP (USPACE_SVC_STACK_BOTTOM - 0x10) > #define USPACE_UNDEF_STACK_BOTTOM (FPCONTEXTSIZE + 10) > + > +#ifndef VM_BCACHE_SIZE_MAX > +#define VM_BCACHE_SIZE_MAX (128 * 1024 * 1024) > +#endif > + > /* > * Mach derived conversion macros > */ I tested it with my changes reverted and it works indeed, so I'm fine with this being committed and my changes being reverted. Regards, Olivier
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130610211358.GA55399>