From owner-freebsd-hackers  Wed Jul 28 21:45:45 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 4742B15584
	for <hackers@FreeBSD.ORG>; Wed, 28 Jul 1999 21:45:42 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id VAA66252;
	Wed, 28 Jul 1999 21:45:40 -0700 (PDT)
	(envelope-from dillon)
Date: Wed, 28 Jul 1999 21:45:40 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199907290445.VAA66252@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)
References:  <199907290439.XAA69977@celery.dragondata.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

: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