Date: Tue, 18 Dec 2012 14:59:58 +0530 From: Mukunda Haveri <mukunda@pointred.co> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-mips@freebsd.org Subject: Re: Help: Reg Out of swap space Message-ID: <CAK3PU_BT0Ww1ODAwEDLpjgXr=hNy=rxMBamrNYXGz%2BuU1AmZwg@mail.gmail.com> In-Reply-To: <CAJ-Vmokb-LhJz10jCwUYpgzaM3nhOiW8yfPDgERjxz1eR9qG9A@mail.gmail.com> References: <CAK3PU_Am17vANaZxGNobSEgU3nVA-MTWw1cY9FFju8xLj%2B81nQ@mail.gmail.com> <CAJ-VmomnbEXN1YJSupw4UAXiPqdO=Bj9c_D=KGi8hzbLGAzE_w@mail.gmail.com> <CAK3PU_BDdLKYsQQCkXKrk5Mh2bFFgMbroxuVDJ9amH-uBuVC8A@mail.gmail.com> <50CFE88E.3020303@bluezbox.com> <266E3514-39BC-4E3C-A5BA-50B4D7DA635E@bsdimp.com> <129337B8-C3C2-4365-8C8D-6F5B6B45DDB1@bluezbox.com> <CAJ-Vmokb-LhJz10jCwUYpgzaM3nhOiW8yfPDgERjxz1eR9qG9A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <adrian@freebsd.org> 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 <gonzo@bluezbox.com>
> wrote:
> >
> > On 2012-12-17, at 8:06 PM, Warner Losh <imp@bsdimp.com> 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 <audisdistd>. -:)
> >>>>
> >>>>
> >>>>
> >>>> On Mon, Dec 17, 2012 at 2:14 PM, Adrian Chadd <adrian@freebsd.org>
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAK3PU_BT0Ww1ODAwEDLpjgXr=hNy=rxMBamrNYXGz%2BuU1AmZwg>