Date: Wed, 28 Jul 1999 21:45:40 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Kevin Day <toasty@dragondata.com> Cc: toasty@dragondata.com (Kevin Day), crandall@matchlogic.com (Charles Randall), hackers@FreeBSD.ORG Subject: Re: Replace/rewrite reverse.c for tail(1) Message-ID: <199907290445.VAA66252@apollo.backplane.com> References: <199907290439.XAA69977@celery.dragondata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:Wow, that's interesting. While I never looked at the code, I *thought* I was
:able to measure a speed boost in a certain large embedded application I'm
:working on, with adding some madvise()'s in to mmap'ed files. (Streaming
:video madvise'ed with MADV_SEQUENTIAL seemed to be slightly faster, but it
:may have been insignificant)
MADV_SEQUENTIAL *WILL* work. It changes the page fault
read-behind/read-ahead. Normally the VM system reads behind a bit as well
as reads ahead. If you set MADV_SEQUENTIAL it shifts to just doing
read-ahead, and it does more of it.
The madvise() types that just flag the VM object work on any type of
object. The madvise() types that actually mess with VM pages currently
only work on swap-backed pages.
MADV_WILLNEED scans for VM pages in object
MADV_DONTNEED scans for VM pages in object
MADV_FREE scans for VM pages in object
MADV_SEQUENTIAL just flags the object
MADV_RANDOM just flags the object
MADV_NORMAL just flags the object
:Granted 'large' is one of those fuzzy terms, but when you do know that the
:900M file you're reading is being done sequentially from start to finish,
:swapping things out to try to keep more of it in swap is probably bad. :)
:
:Kevin
I agree completely. When you run through the filesystem these pages
will be reused more quickly. When you run through the VM system
these pages are considered to be more 'active'.
I think it makes sense to have madvise() MADV_WILLNEED and MADV_DONTNEED
operate on file mmaps. There is a slight security concern with
MADV_DONTNEED (i.e. if you loop running it on a system file that is
used a lot, like /etc/group), but after thinking about it a bit I do not
think it is a big deal.
-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?199907290445.VAA66252>