From owner-freebsd-hackers Thu Jul 29 10:52:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 1FC5C15118 for ; Thu, 29 Jul 1999 10:52:28 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA76835; Thu, 29 Jul 1999 10:52:02 -0700 (PDT) (envelope-from dillon) Date: Thu, 29 Jul 1999 10:52:02 -0700 (PDT) From: Matthew Dillon Message-Id: <199907291752.KAA76835@apollo.backplane.com> To: Jason Thorpe Cc: "Daniel C. Sobral" , hackers@FreeBSD.ORG Subject: Re: MADV_SEQUENTIAL and GNU Grep References: <199907291741.KAA00195@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :When I implemented MADV_DONTNEED and MADV_FREE in NetBSD (UVM): : : DONTNEED: deactivate pages There are some medium sized problems with doing this under FreeBSD, mainly that this will cause the pages to recycle through the inactive and cache queues. Without anything to bump the page daemon you can get into a silly-recycle state when the inactive and cache page queues are too small. For example, if you have 64MB of main memory, 50MB active, 5MB inactive, and 8MB cache, and you scan a 16MB file. This file would trivially fit into main memory but the silly-recycle problem causes it to essentially be completely flushed. We also have another problem: By recycling the pages into the inactive queue we essentially flush the inactive & cache queues when scanning very large objects even though it is a complete waste of memory to do so since the whole of the object will go down the drain anyway... it would have been much, much better to cycle the cache in that case and leave the inactive queue intact. I am working on a solution that attempts to slowly balance the paging queues while at the same time optimizing which queue the madvised page is moved to. If we do it right, it should be possible to scan very large objects without destroying the rest of the VM cache. : FREE: don't clean dirty pages, free all pages in range : :It was fairly straightforward in NetBSD. Yes, we already do this, but only for OBJT_DEFAULT and OBJT_SWAP objects. We do not do this for file objects... it would make me rather nervous if we did :-) : -- Jason R. Thorpe -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message