From owner-svn-src-head@FreeBSD.ORG Mon Jun 10 23:11:17 2013 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BCF2F4BD; Mon, 10 Jun 2013 23:11:17 +0000 (UTC) (envelope-from cognet@ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:150:ca0a:a9ff:fef1:a4c9]) by mx1.freebsd.org (Postfix) with ESMTP id 54DA11978; Mon, 10 Jun 2013 23:11:17 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.5/8.14.5) with ESMTP id r5ANArCq057180; Tue, 11 Jun 2013 01:10:53 +0200 (CEST) (envelope-from cognet@ci0.org) Received: (from doginou@localhost) by kanar.ci0.org (8.14.5/8.14.5/Submit) id r5ANAqf4057179; Tue, 11 Jun 2013 01:10:52 +0200 (CEST) (envelope-from cognet@ci0.org) X-Authentication-Warning: kanar.ci0.org: doginou set sender to cognet@ci0.org using -f Date: Tue, 11 Jun 2013 01:10:52 +0200 From: Olivier Houchard To: Konstantin Belousov Subject: Re: svn commit: r251586 - head/sys/arm/ti Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130610211358.GA55399@ci0.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, Alan Cox X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 23:11:17 -0000 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 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. > 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. Regards, Olivier