Date: Mon, 10 Jun 2013 22:37:36 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Alan Cox <alc@rice.edu> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, Olivier Houchard <cognet@ci0.org> Subject: Re: svn commit: r251586 - head/sys/arm/ti Message-ID: <20130610193736.GF3047@kib.kiev.ua> In-Reply-To: <51B6069C.6060704@rice.edu> References: <201306092251.r59MpCmW006162@svn.freebsd.org> <20130610035547.GX3047@kib.kiev.ua> <20130610110847.GA46614@ci0.org> <51B6069C.6060704@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--0kF7NMh4V20xOF8g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 sud= denly 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, 200= M, as > > it is on i386 ? > > >=20 > 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 */ --0kF7NMh4V20xOF8g Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRtir/AAoJEJDCuSvBvK1Bc3EP/0x7/43VmJr1gaRRGR9suJDr DZfnpLVqMKPgMotOzF96y4K0OvI/3WUul0lrZc/QXIre5c13leJ0XQEqqjr1juOO lGsdSyRMwxbn0auMePcV2WE1+VKhTPRHd73KHeQI7e5EjTYvcu1Mx9AlpR+nOw/+ q2Rjhw/gSwr/xEv+TFUhuMnUs6wZQSPB9wkBT0yq25CJCl35SkwL70FAyByvLDtI vUplqSgZ9HHI9NsPCWVY34ga5IqV63s5M8EofjyigvES7GntFbcF0YlXxBeu3iOy DF0L3JmTKPclBL4VZ8w4qIw4Nkx1VCggIxnB3vaf34GGubJYe4tYRBgXoGOj/yxB ZX79pizEGznwMGWd8rkKsOjlkHFdSPRUodb0XD44UZzxtZYwccGFxpa6PgxVVjT4 uGrty84PNDKRcl04U/MjcHyD8YuIs74fGucydZMT34wxAgN9bARCctNaaVt43yfc rE/w+mn336CSLjrmpdo+8MSJ9Z4GA4DFB6qh0DFLm7gwGHxpJ51Yp1M+7h6+nsLs xekDAosIZoA0nRSZ20MJ20ouUySrAYaQJqvC4gZ4CltbW/w3hKx8j1wJz9sNfHvF Z1gOYVOyAQdWLFu9WL7HOk8kEj2G+rcY5KmHKfpx8vOf675QM0G2gUyejiOZGcne lDpCIYn8MKq5JhatKVCB =kR7R -----END PGP SIGNATURE----- --0kF7NMh4V20xOF8g--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130610193736.GF3047>