From owner-freebsd-arch@FreeBSD.ORG Wed Apr 18 22:23:27 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C23C51065675 for ; Wed, 18 Apr 2012 22:23:27 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 80D638FC0A for ; Wed, 18 Apr 2012 22:23:27 +0000 (UTC) Received: by iahk25 with SMTP id k25so14355639iah.13 for ; Wed, 18 Apr 2012 15:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tynP4/vue7dv9jioLj/dw8tzK/JV0OITJnSHMFktaZQ=; b=pPt0FSRMi04Ndodkb6X96qosbojQgf5fg/JS3z+8eXqWVhzyJhqC2PH2BN/ksMNHNw 1C5nahBqzsxie/MBPZJpLKEMt6MW/t3Y4Ger1oswfuf57kXseFr1C82Dz5VVnWxBY4mw /QJCrl9AOlSDCSv+wQGGFnaKAcsKC/3kcxWOs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=tynP4/vue7dv9jioLj/dw8tzK/JV0OITJnSHMFktaZQ=; b=EefDUvsSa1KQ1oiHjTv5cEYWt4wzqf5rOzaWShKHjsrOV8J2KTC+kbhISLxJM0wk9Q QDCq3WiZl5ghTRRwkIR/Bc6HVhUUksMXis/lBcqDtLFoYrGjCfRScdcAZNfEsgxXlSMg xaDcSB09byH4NxUzWyQezIB6yROthtYRuolaurfPFqVPondkcWCaatBIP2YogDJGGNI1 o0fcBYxym57tpEP8ltSmpL1+KJfLnxsnXfxc2W9bEFTwPZpW7NnoDDfDlCV41VW0tF3X hhRxCHwodsuE/NjS0MU8QxkCiYTS3XwSMcY5sMQ0H54MWe7DFz/HhzmHjq9lYcsTp8Jq SoRQ== MIME-Version: 1.0 Received: by 10.50.216.132 with SMTP id oq4mr3982833igc.6.1334787807146; Wed, 18 Apr 2012 15:23:27 -0700 (PDT) Received: by 10.231.172.138 with HTTP; Wed, 18 Apr 2012 15:23:27 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Apr 2012 15:23:27 -0700 Message-ID: From: Peter Wemm To: Robert Millan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkJrDfFlsbDEtj4wsDpt0MZSb9zB/l1cQaVCctCOIN1YDMP2ZZVJGJcIY5Ksp4aX6knVUNl Cc: freebsd-arch@freebsd.org Subject: Re: Increase DFLDSIZ on amd64? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 22:23:27 -0000 On Wed, Apr 18, 2012 at 2:41 PM, Robert Millan wrote: > Hi, > > Is there any reason for DFLDSIZ being so low (128 MiB) on amd64? > We've recently had a bunch of trouble in Debian when attempting to run > the CMOR testsuite. =A0Its testcases require about ~700 MiB to pass. =A0W= e > also found references recommending higher values for applications like > SAP [2] or MySQL [3]. > > I understand on i386 there's a shortage of virtual memory, but on > amd64 there's plenty of it. =A0It seems this is already reflected on the > MAXDSIZ setting (32 GiB), but DFLDSIZ is still the same as on i386. > Wouldn't 32 GiB be a sound value as the default limit too? =A0Is there > any unreasonable cost or security consideration associated with > allocating so many pages? Hmm. In login,conf, we have: :datasize=3Dunlimited: .. which causes the datasize limit to be pushed to 32G by default at login/cron/sshd/etc. 128M is too small, but I'm curious about how this would be getting exposed to users. All the setusercontext() stuff should be fixing that, and if not then something is missing. Also, malloc doesn't use this pool on amd64 - it comes straight out of mmap MAP_ANON page blocks. The only that should be hitting it ever would be things that call the old sbrk(3) interface directly. Malloc shouldn't be hitting it. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell