From owner-freebsd-mips@FreeBSD.ORG Tue Dec 18 09:30:05 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD35BE4F for ; Tue, 18 Dec 2012 09:30:05 +0000 (UTC) (envelope-from mukunda@pointred.co) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by mx1.freebsd.org (Postfix) with SMTP id 3BE668FC1C for ; Tue, 18 Dec 2012 09:30:05 +0000 (UTC) Received: from mail-qa0-f71.google.com ([209.85.216.71]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKUNA3l4lYxGBS0XmUB15NRy78LLl9HvRy@postini.com; Tue, 18 Dec 2012 01:30:05 PST Received: by mail-qa0-f71.google.com with SMTP id i20so1060570qad.2 for ; Tue, 18 Dec 2012 01:29:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=0WImNPaenB2Q4cuw9mcGfl841MJReoh+dNaw5uK89q8=; b=ofVVyQbwah6CnBmT/V13cwSsEmArOWmlD/MKiEGWYogTsAW2dizGLJEoQemZv49yNb X1/1HuBu81gIVnoOjZ+Z1aHdcdEx7NhStTOdcez9GV3bGXjuMM9QrNjCNKvKsCO0pLxV 1MYtd5qOvEVfmq/eHVZMJvUmUT70qvCEKsgQx74jWlkBy4cIqOhqNbzvXBHzOlJx/JWC TJ/1VF+7JmY/WpodngYl3XrS9aWY876LIwYsN731RQuRhXvuRYQK4dxf5ukwIp8iZ5bw 241B4d+12nQExI3zeKCXywtPecLqha99OqNKP9zRSxoJc/yzA0/COBP6/6croGfHMQJt J0yw== X-Received: by 10.220.150.84 with SMTP id x20mr1800322vcv.73.1355822999054; Tue, 18 Dec 2012 01:29:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.150.84 with SMTP id x20mr1800306vcv.73.1355822998907; Tue, 18 Dec 2012 01:29:58 -0800 (PST) Received: by 10.58.143.104 with HTTP; Tue, 18 Dec 2012 01:29:58 -0800 (PST) In-Reply-To: References: <50CFE88E.3020303@bluezbox.com> <266E3514-39BC-4E3C-A5BA-50B4D7DA635E@bsdimp.com> <129337B8-C3C2-4365-8C8D-6F5B6B45DDB1@bluezbox.com> Date: Tue, 18 Dec 2012 14:59:58 +0530 Message-ID: Subject: Re: Help: Reg Out of swap space From: Mukunda Haveri To: Adrian Chadd X-Gm-Message-State: ALoCoQntBHPy3gdBBn5bMPc37sMfAwPE42TQSG156eT10bp8tXAZt8wkxvrX3mXpV0oNgkxBvZ18rLbc3Ja2AbtSCsfDV1avww9E3LWrE/2iliC2qE2MnDEcjKcGQ5IiYiogP6NCLHvWKbZqS8GzFYknDP9z3i2ZooeZ5O0dYB4Z8aLtIkeNG7A= Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-mips@freebsd.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 09:30:05 -0000 In any case, I would like to confirm that defining WITHOUT_MALLOC_DEBUG enabled me to run the system further and mount the NFS. Thanks. I think we need a clear list of all the compile/make definitions that alter/govern the system image and behavior. Thanks, HSM On Tue, Dec 18, 2012 at 12:25 PM, Adrian Chadd wrote: > i386 would suffer if it ran on say, 64 or 128mb ram. > > I don't think it's a tier X question, I think it's a "hey, everything > has ${LOTS} of real RAM, let's make the allocator assume that!" design > from Jason. > > Which is fine for the systems Jason is running on, but not for other > situations. > > Honestly, I think we should write some patches to jemalloc to > implement a better default set of behaviours (including run-time > configuration tweaks to set default parameters like arena sizes, etc) > and hand that off to Jason to push into his next install of jemalloc. > > Thanks, > > > > Adrian > > > On 17 December 2012 21:57, Oleksandr Tymoshenko > wrote: > > > > On 2012-12-17, at 8:06 PM, Warner Losh wrote: > > > >> > >> On Dec 17, 2012, at 8:52 PM, Oleksandr Tymoshenko wrote: > >> > >>> On 12/17/2012 2:32 AM, Mukunda Haveri wrote: > >>>> I have done that already. Hope it's correct.. > >>>> Please have a look at the attached make.mips.conf. and my build > script (csh > >>>> script) sets, > >>>> setenv __MAKE_CONF /root/mips/make.conf.mips > >>>> setenv SRCCONF /root/mips/src.conf.mips > >>>> > >>>> I also have a new problem after updating the source to head [from 24k+ > >>>> version]. Something related to . -:) > >>>> > >>>> > >>>> > >>>> On Mon, Dec 17, 2012 at 2:14 PM, Adrian Chadd > wrote: > >>>> > >>>>> You need to define MALLOC_PRODUCTION in your build or the default > >>>>> jemalloc options in -HEAD cause it to run out of RAM on embedded > >>>>> platforms. > >>>>> > >>>>> > >>> > >>> As far as I can see it's MALLOC_DISTRIBUTION in make.conf. Should be > MALLOC_PRODUCTION > >> > >> It should be WITHOUT_MALLOC_DEBUG > >> > > > > BTW, why not make it a default for platforms with small footprint or > non-tier1? As far as I understand > > the idea behind having debug enabled is to make getting information from > running systems > > easier. I do not think this approach is applicable to ARM or MIPS > targets. > > > > _______________________________________________ > > freebsd-mips@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" > DISCLAIMER: The information contained in this message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and permanently delete this message and any attachments from your system. Any dissemination, use, review, distribution, printing or copying of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. PointRed Telecom Ltd (including its group companies) shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system and does not guarantee that the integrity of this communication has been maintained or that this communication is free of viruses, interceptions or interferences.