From owner-freebsd-hackers Fri Jul 16 4:16:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 4A57514E64 for ; Fri, 16 Jul 1999 04:16:09 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id OAA13658; Fri, 16 Jul 1999 14:09:08 +0300 (EEST) (envelope-from will) To: cgd@netbsd.org (Chris G. Demetriou) Cc: hackers@freebsd.org, dillon@apollo.backplane.com Subject: Re: Replacement for grep(1) (part 2) References: <199907132110.OAA23817@lestat.nas.nasa.gov> <871zecyx0k.fsf@redmail.redback.com> From: Ville-Pertti Keinonen Date: 16 Jul 1999 14:09:07 +0300 In-Reply-To: cgd@netbsd.org's message of "14 Jul 1999 02:03:32 +0300" Message-ID: <86iu7kn964.fsf@not.demophon.com> Lines: 36 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG cgd@netbsd.org (Chris G. Demetriou) writes: > Matthew Dillon writes: > > The text size of a program is irrelevant, because swap is never > > allocated for it. The data and BSS are only relevant when they No, you can mprotect read-only vnode mappings to writable. Most things wouldn't be hurt badly if this changed, though, I suspect that this already varies between operating systems. > > are modified. > > > > The only thing swap is ever used for is the dynamic allocation of memory. > > There are three ways to do it: sbrk(), mmap(... MAP_ANON), or > > mmap(... MAP_PRIVATE). > yup, almost: not all MAP_PRIVATE mappings need backing store, only > MAP_PRIVATE and writeable mappings. (MAP_PRIVATE does _not_ guarantee > that you won't see modifications made via other MAP_SHARED mappings.) ...but in *this* case, you certainly shouldn't allow mprotect to fail (with what, ENOMEM?). It's certainly counterintuitive to me that mprotect could fail due to a resource shortage. > Actually, only now have you brought that up. And, that's very system > dependent. On NetBSD/i386 the default is 2MB, and, it's worth noting > that you only need to reserve as much as the current stack limit > allows (after that, you're going to get a signal anyway, and if more So what setrlimit accepts depends on how much memory is available? Ok, programs changing their stack limit are rare, but this would still be another API change. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message