From owner-svn-src-head@FreeBSD.ORG Tue Jun 11 09:50:31 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 083C1CEF; Tue, 11 Jun 2013 09:50:31 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id BDA5E18FC; Tue, 11 Jun 2013 09:50:30 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id at1so15235177iec.37 for ; Tue, 11 Jun 2013 02:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=RAt1U6ttNE2O18fDzENFKdYfD0uek4RNoyjx8G4JnAo=; b=D0hng7x7tv9f6TSuTFHo+9E8hFwNTeUrS9qr+HsYot5ewt3DKB7iUSUIAVlJqTbLHR cUiGx/V8Uqb6jQKDASLuzXZBuGthhkRsNHl8e8a7NZK98ZC7ZQK+Pgdv+I/sAAcX48XA jwFEcznMYK8Kw5+prof8pCujquQGLYsBV0UeERJ11SK65ykHhJlU/T8s0LonoTAsf9nV 2PYjht0X98PHNE4rw0rLkdY4z2oNd0g+AP3CsCzLj3+llljFZud5VWKtPvHEfvMkyHbx ID5gdqAk1bcvjljEbmw+15Fj8gdDUWFkg2EQ7APfyvCU4symIUogM6MwemyHpcQFLuY/ k89g== MIME-Version: 1.0 X-Received: by 10.50.152.37 with SMTP id uv5mr516068igb.13.1370944230321; Tue, 11 Jun 2013 02:50:30 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.42.253.129 with HTTP; Tue, 11 Jun 2013 02:50:30 -0700 (PDT) In-Reply-To: <20130611052152.GG3047@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> <20130610211358.GA55399@ci0.org> <20130610231052.GA57152@ci0.org> <20130611052152.GG3047@kib.kiev.ua> Date: Tue, 11 Jun 2013 11:50:30 +0200 X-Google-Sender-Auth: FI5TRG31ZavfjxtJrpFIfpc1wbA Message-ID: Subject: Re: svn commit: r251586 - head/sys/arm/ti From: Attilio Rao To: Konstantin Belousov , Jeff Roberson Content-Type: text/plain; charset=UTF-8 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Olivier Houchard , Alan Cox X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org 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: Tue, 11 Jun 2013 09:50:31 -0000 On Tue, Jun 11, 2013 at 7:21 AM, Konstantin Belousov wrote: > 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 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. > > 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 discussed with Jeff a way to not depend by the preallocated pool of nodes and I think we can fix it. However I still have to finish some things before to get into this but I will try to commit to this before code slush. Attilio -- Peace can only be achieved by understanding - A. Einstein