Date: Thu, 29 Jul 1999 10:52:02 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Jason Thorpe <thorpej@nas.nasa.gov> Cc: "Daniel C. Sobral" <dcs@newsguy.com>, hackers@FreeBSD.ORG Subject: Re: MADV_SEQUENTIAL and GNU Grep Message-ID: <199907291752.KAA76835@apollo.backplane.com> References: <199907291741.KAA00195@lestat.nas.nasa.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
: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 <thorpej@nas.nasa.gov>
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907291752.KAA76835>