Date: Tue, 11 Jun 2013 08:21:52 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Olivier Houchard <cognet@ci0.org> 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: <20130611052152.GG3047@kib.kiev.ua> In-Reply-To: <20130610231052.GA57152@ci0.org> References: <201306092251.r59MpCmW006162@svn.freebsd.org> <20130610035547.GX3047@kib.kiev.ua> <20130610110847.GA46614@ci0.org> <51B6069C.6060704@rice.edu> <20130610193736.GF3047@kib.kiev.ua> <20130610211358.GA55399@ci0.org> <20130610231052.GA57152@ci0.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nBxkCaiRhNuisgbJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 11, 2013 at 01:10:52AM +0200, Olivier Houchard wrote: > On Mon, Jun 10, 2013 at 11:13:58PM +0200, Olivier Houchard wrote: > > 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 wro= te: > > > > >> 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 (?) pro= blem 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 valu= e, 200M, as > > > > > it is on i386 ? > > > > > > > > >=20 > > > > Since there are many arm platforms with less than 1 GB of kernel vi= rtual > > > > 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. > > >=20 > > > 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. > > >=20 > > > Alexander Motin reported that he tested the equivalent of the followi= ng > > > change. With it committed, I think that r251586 could be reverted. > > >=20 > > > 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 > > > */ > >=20 > >=20 > > I tested it with my changes reverted and it works indeed, so I'm fine w= ith > > this being committed and my changes being reverted. > >=20 >=20 > In fact I spoke too soon. It's getting further, but I'm ending up getting > vm_thread_new: kstack allocation failed > Probably because I have a local patch that aligns the stack on 32kB, which > is something we have to do if we want to store curthread on the kstack. > It will boot if I reduce VM_DCACHE_SIZE_MAX to 64MB, but it's probably not > the best thing to do. The other cause of increased KVA use is the vm radix trie used to keep the collection of the vm object' pages. When I profiled KVA use for PAE on i386, which has similar problem of exhausted KVA, the radix trie popped up as the reason. IMO the current sizing of the trie for the worst case is not attainable for any practical situation. Anyway, this is separate. I will commit the bcache limit change after make universe passes. --nBxkCaiRhNuisgbJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRtrPwAAoJEJDCuSvBvK1BhCwP/REMjlmZKV0xTjS0qSDDK+qB McEkNIxTWRPKXCrbMplCWPACQtHKRf5OZe4CderAVz3YT+MgJgWB1xSt5nkR6wda XZn4ozqm2GXuLMpxa09UqW97sxCYwR1ShZ313dv07gpAmUCDEpb/SIXtWDfufHzt qKM8Gtml9Z2soNCThRLDs/FOy3nYcsYCuC5Gn82/qbbk/MMFZEtVZGHJPnynOrbk 2IZr6HAQHOt0yfa7gxU2WMqiaH6aE3t+ITZ+ZtZ0cc7brXE0CWHn5uW+HSpyZhb/ jeuDgeUa1Re4w10cHkvm48YkfdRr4Doq5RqzXo8Bjc6XuFeik9ge37kCpb/Rf67z wYdRXscbGd+2xS6qfG1zINGoixTrbnUfHOiBsY1pS32cdXBnMheu8cOee+8vTlHG PRolFEO14plFKhtPwd2CJ1bndf7+NLk7SSH5D9cv3tRnReacGM7hqnBNAsmYT+7f 206FytsKd40Wf/UiqavexGGGl4E4f+ySLki6OgS5Jg+nVS0daFwLuAwTYudK0SF+ 4ns09tTop8XsErb2qWGiDc2jz+RuNEXMXXfYQi5QEbzO4Ga0owNNisxdrz3aL5Ls 34Tix+XQAlW1tdAstkCKBsc9UhZ5+qIM4CCUHwrztawu/1WiAORBJXAJHeN5CNC2 6CZInDf1C2OMKIJfWfla =+9QD -----END PGP SIGNATURE----- --nBxkCaiRhNuisgbJ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130611052152.GG3047>