From owner-freebsd-hackers Mon Dec 4 10:23:18 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 10:23:16 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 3ECE237B400 for ; Mon, 4 Dec 2000 10:23:16 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB4IN9g73689; Mon, 4 Dec 2000 10:23:09 -0800 (PST) (envelope-from dillon) Date: Mon, 4 Dec 2000 10:23:09 -0800 (PST) From: Matt Dillon Message-Id: <200012041823.eB4IN9g73689@earth.backplane.com> To: Brooks Davis Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/sys mmap.2 References: <200012032017.eB3KHaC61682@freefall.freebsd.org> <20001204094700.B546@Odin.AC.HMC.Edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :I've got a (hopefully) quick question about this warning. If I'm using :mmap to create shared memory segments and I don't care about the :contents of the file after the run does this fragmentation hurt me? I'm :asking because I've got code that uses up to 1.3GB of mmaped storage. :The mmaped storage may be larger then physical memory at this point, but :the portion I actually use should fit in RAM. : :Thanks, :Brooks If you remove() the file after use then I don't think it will matter... the dirty pages will be thrown away when the last descriptor reference goes away and the file is removed. Certainly for small files (less then 20MB) it is entirely irrelevant. For lager files it may be a good idea to force creation of the backing store (by write()ing zero's) to avoid long crash/reboot times from the system trying to flush the dirty pages, and to avoid the situation where the filesystem runs out of space while trying to allocate backing store, which will seg-fault the process. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message