From owner-freebsd-arch@FreeBSD.ORG Wed Apr 18 21:41:30 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 E89F11065673 for ; Wed, 18 Apr 2012 21:41:30 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id ADE778FC14 for ; Wed, 18 Apr 2012 21:41:30 +0000 (UTC) Received: by iahk25 with SMTP id k25so14302139iah.13 for ; Wed, 18 Apr 2012 14:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=Yog46hXnCFtZju+1v5UNh4sWCFYtq3dr6ZvcfOaQZtY=; b=ns0L4GjGOFiF4ciwMK9Seg0qiUvlT59aVP/+8ufkMy9F+gOlhSw5oz8cGqr3RyofO3 wZKmiG/uY8lQxqEzfSLcmUV/K/gpBfh+q8lvuChvWw9ooQ6KO9ZEMQrXSjL6TqRzUq9Z I6ZhD/BeFCgJesTLfybNXCuV55+DPbeFvs0YF66SnfRNtuWOD72IsMizxrxBsc5KnB2i p16F0ztdZwma8dex8Zetfglwo6t+mSsP5UtmUj1WJCVNaGxty3NzLAPx0pilMrsvs9FS cEbEHgZomvqatwy/E06nVpKUEL84lyH/NgTwcFTvuJyTfb02K9U/0HHrPux+swBHj5lY 9Mwg== MIME-Version: 1.0 Received: by 10.50.190.130 with SMTP id gq2mr14577815igc.43.1334785290178; Wed, 18 Apr 2012 14:41:30 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.43.130.201 with HTTP; Wed, 18 Apr 2012 14:41:30 -0700 (PDT) Date: Wed, 18 Apr 2012 23:41:30 +0200 X-Google-Sender-Auth: Or0SkZWAI1GPOF37EoUjuob4CJ4 Message-ID: From: Robert Millan To: freebsd-arch@freebsd.org Content-Type: multipart/mixed; boundary=f46d0447a2471291b704bdfaeb9c Subject: 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 21:41:31 -0000 --f46d0447a2471291b704bdfaeb9c Content-Type: text/plain; charset=UTF-8 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. Its testcases require about ~700 MiB to pass. We 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. It 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? Is there any unreasonable cost or security consideration associated with allocating so many pages? Thanks [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661283 [2] http://www.freebsd.org/doc/handbook/sapr3.html#KERNELTUNING [3] https://dev.mysql.com/doc/refman/5.0/en/freebsd.html -- Robert Millan --f46d0447a2471291b704bdfaeb9c Content-Type: application/octet-stream; name="data_size_limit.diff" Content-Disposition: attachment; filename="data_size_limit.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h16wkd0w0 SW5kZXg6IHN5cy9hbWQ2NC9pbmNsdWRlL3ZtcGFyYW0uaAo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvYW1k NjQvaW5jbHVkZS92bXBhcmFtLmgJKHJldmlzaW9uIDIzNDM4OSkKKysrIHN5cy9hbWQ2NC9pbmNs dWRlL3ZtcGFyYW0uaAkod29ya2luZyBjb3B5KQpAQCAtNTQsNyArNTQsNyBAQAogICovCiAjZGVm aW5lCU1BWFRTSVoJCSgxMjhVTCoxMDI0KjEwMjQpCS8qIG1heCB0ZXh0IHNpemUgKi8KICNpZm5k ZWYgREZMRFNJWgotI2RlZmluZQlERkxEU0laCQkoMTI4VUwqMTAyNCoxMDI0KQkvKiBpbml0aWFs IGRhdGEgc2l6ZSBsaW1pdCAqLworI2RlZmluZQlERkxEU0laCQkoMzI3NjhVTCoxMDI0KjEwMjQp CS8qIGluaXRpYWwgZGF0YSBzaXplIGxpbWl0ICovCiAjZW5kaWYKICNpZm5kZWYgTUFYRFNJWgog I2RlZmluZQlNQVhEU0laCQkoMzI3NjhVTCoxMDI0KjEwMjQpCS8qIG1heCBkYXRhIHNpemUgKi8K --f46d0447a2471291b704bdfaeb9c-- 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 From owner-freebsd-arch@FreeBSD.ORG Fri Apr 20 18:47:54 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 AEF3C106568A for ; Fri, 20 Apr 2012 18:47:54 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 666668FC0A for ; Fri, 20 Apr 2012 18:47:54 +0000 (UTC) Received: by yenl9 with SMTP id l9so6488208yen.13 for ; Fri, 20 Apr 2012 11:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nR9XIViT21QmCz5JFLbBnmcvW0UpVjCEpKN90/zaG4U=; b=KCEevkpld/u9APluOZJCyv4z99Y/rN4qqFMQS/D+qp5KNSC0zMH6PTYPWCz2MBIEHt BipOmhPLhxgG9FpUA+SvlY6wKOjgY3K8m/0I1kif0xJdCH2yHwy7vrEJRwWtrtP+yO4u /2BPR+TY4pG2Lkt78G/uxz4Qjux91LgwXJdocjIKChemBiFTfYTHjJCdj0MnP5AH8UBp Gt2RVsqU3vqXyctMHWn28DfnVQvlX00ldqjtrcuUOJJYig1t4QcvqpLPS7jWahJwLos7 +YtB8wM5FtuZ1Mv235kL7kj4Pj8HLa+bN7AYL/V7vT4wnQpV+h1IWPhpPIFoKPBqgEgg OxgQ== MIME-Version: 1.0 Received: by 10.50.202.100 with SMTP id kh4mr7393298igc.43.1334947665845; Fri, 20 Apr 2012 11:47:45 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.43.130.201 with HTTP; Fri, 20 Apr 2012 11:47:45 -0700 (PDT) In-Reply-To: References: Date: Fri, 20 Apr 2012 20:47:45 +0200 X-Google-Sender-Auth: fnpSYkIoav21Ei3wmj-lRFAH-IY Message-ID: From: Robert Millan To: Peter Wemm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Fri, 20 Apr 2012 18:47:54 -0000 Hi Peter, El 19 d=E2=80=99abril de 2012 0:23, Peter Wemm ha escrit: > Hmm. =C2=A0In login,conf, we have: > :datasize=3Dunlimited: > .. which causes the datasize limit to be pushed to 32G by default at > login/cron/sshd/etc. Well, Debian has a similar facility, but I don't think this solves the problem, as it only covers processes that descend from a login shell. What about daemons? > Also, malloc doesn't use this pool on amd64 - it comes straight out of > mmap MAP_ANON page blocks. =C2=A0The only that should be hitting it ever > would be things that call the old sbrk(3) interface directly. =C2=A0Mallo= c > shouldn't be hitting it. I hit trouble with the dynamic linker: # cat test.c char buf[1024*1024*1024]; int main () { } # gcc test.c -o test # ./test Abort trap: 6 Not sure about other things but IMHO it's a valid reason to increase the default to match with the one set by userland. --=20 Robert Millan From owner-freebsd-arch@FreeBSD.ORG Fri Apr 20 18:55:52 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 016901065672; Fri, 20 Apr 2012 18:55:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 6F27D8FC21; Fri, 20 Apr 2012 18:55:51 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3KIthVG083333; Fri, 20 Apr 2012 21:55:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3KIthQ5017848; Fri, 20 Apr 2012 21:55:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3KIth7W017847; Fri, 20 Apr 2012 21:55:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 20 Apr 2012 21:55:43 +0300 From: Konstantin Belousov To: Robert Millan Message-ID: <20120420185543.GU2358@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mL1UijcviCmf7HKk" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua 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: Fri, 20 Apr 2012 18:55:52 -0000 --mL1UijcviCmf7HKk Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 20, 2012 at 08:47:45PM +0200, Robert Millan wrote: > Hi Peter, >=20 > El 19 d???abril de 2012 0:23, Peter Wemm ha escrit: > > Hmm. =9AIn login,conf, we have: > > :datasize=3Dunlimited: > > .. which causes the datasize limit to be pushed to 32G by default at > > login/cron/sshd/etc. >=20 > Well, Debian has a similar facility, but I don't think this solves the > problem, as it only covers processes that descend from a login shell. > What about daemons? >=20 > > Also, malloc doesn't use this pool on amd64 - it comes straight out of > > mmap MAP_ANON page blocks. =9AThe only that should be hitting it ever > > would be things that call the old sbrk(3) interface directly. =9AMalloc > > shouldn't be hitting it. >=20 > I hit trouble with the dynamic linker: >=20 > # cat test.c > char buf[1024*1024*1024]; > int > main () > { > } > # gcc test.c -o test > # ./test > Abort trap: 6 >=20 > Not sure about other things but IMHO it's a valid reason to increase > the default to match with the one set by userland. Just for record, this is not an issue with dynamic linker. Kernel image activator returns error if data segment size is larger then RLIMIT_DATA value, see imgact_elf.c:901. Then, since the address space of the program which called execve(2) is already destroyed when segment mapping is performed, kernel has no other choice and kills the process. --mL1UijcviCmf7HKk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+RsS8ACgkQC3+MBN1Mb4gV/QCgqnjq1Q4d+q9YQQpS0jKzQQCX t+MAoJFJjPzL88TLITx4TtVnU1DsYHcr =5kdP -----END PGP SIGNATURE----- --mL1UijcviCmf7HKk-- From owner-freebsd-arch@FreeBSD.ORG Sat Apr 21 00:41:29 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E8CC106566B for ; Sat, 21 Apr 2012 00:41:29 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 329D38FC12 for ; Sat, 21 Apr 2012 00:41:29 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id E1CD8ED371 for ; Sat, 21 Apr 2012 02:41:19 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id Xz3SSFqlXHWf for ; Sat, 21 Apr 2012 02:41:19 +0200 (CEST) Received: from [172.17.136.194] (adsl-66-120-169-242.dsl.sntc01.pacbell.net [66.120.169.242]) by smtp.semihalf.com (Postfix) with ESMTPSA id DD19AED0C4 for ; Sat, 21 Apr 2012 02:41:18 +0200 (CEST) Message-ID: <4F920234.8060105@semihalf.com> Date: Sat, 21 Apr 2012 02:41:24 +0200 From: Grzegorz Bernacki User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: arch@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Request for comments - NAND Framework & NandFS 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: Sat, 21 Apr 2012 00:41:29 -0000 Hi, We work on integration our work on NAND Framework into -current. Our project consist of: - NAND Framework which allows treat NAND Flash Chip as storage devices, - NANDSim which is kernel driver which emulates ONFI-compliant chip devices and userspace tool to configure/manage created devices, - NandFs which is log filesystem which is targeted for NAND chip storage devices. Currently our work is merged into "nand" branch under project directory (http://svnweb.freebsd.org/base/projects/nand/). Currently we are still working on fixing existing bugs and cleaning up the code. We are going to start merge in into HEAD on on May 7th. I would like to ask you to review the code and let us know if you have any comments or concerns. thanks, grzesiek From owner-freebsd-arch@FreeBSD.ORG Sat Apr 21 08:58:22 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 9BA05106564A for ; Sat, 21 Apr 2012 08:58:22 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5DA6F8FC12 for ; Sat, 21 Apr 2012 08:58:22 +0000 (UTC) Received: by iahk25 with SMTP id k25so18730611iah.13 for ; Sat, 21 Apr 2012 01:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=K2bqYMPbuIFcL5KKdjUFlPn1LQLj77rGLoLVhIag750=; b=rpY9cExkl/+UICRASN8SaOe4D3yGCyK9Pg2Vqo1LGmro+nOE0yp69sMzP8MoaA16Cr t8UcD0KotbwD7IKRMex929A6tH/aTPkI05W+IjYbi9/5GOmJadUR9sTB50XZF0T0NTA3 6/t1sQZ+vWYdlwF4xrvp13fCx51LJavLB30E7Br9pEe0ni/4tk1BYCBB7XlvrYhDS3MI o2o5H5Fu4ryNyNOAfuYmkdHqo+HURZBRhbEtYknUtT96MpFJjIOXsCpS75iAUVbJWjBs QFcVv3TamAxqQEDJuGu0cxiOBXyTeOO2NcAWbKITO2KaPiUQVwB6h0wqfiUD7bAXSQGV 971g== MIME-Version: 1.0 Received: by 10.50.191.200 with SMTP id ha8mr1289902igc.45.1334998701846; Sat, 21 Apr 2012 01:58:21 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.43.130.201 with HTTP; Sat, 21 Apr 2012 01:58:21 -0700 (PDT) In-Reply-To: <20120420185543.GU2358@deviant.kiev.zoral.com.ua> References: <20120420185543.GU2358@deviant.kiev.zoral.com.ua> Date: Sat, 21 Apr 2012 10:58:21 +0200 X-Google-Sender-Auth: Sk6vl-ZgL9hUURK_WTJt9PecgaE Message-ID: From: Robert Millan To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Sat, 21 Apr 2012 08:58:22 -0000 El 20 d=E2=80=99abril de 2012 20:55, Konstantin Belousov ha escrit: > Just for record, this is not an issue with dynamic linker. > Kernel image activator returns error if data segment size is larger > then RLIMIT_DATA value, see imgact_elf.c:901. I see. So if it can't be handled gracefully in userland, the more reason to avoid it... Is there any objection to increasing DFLDSIZ as proposed? --=20 Robert Millan