Date: Thu, 29 Jul 1999 10:21:52 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Jason Thorpe <thorpej@nas.nasa.gov>, "Daniel C. Sobral" <dcs@newsguy.com>, hackers@FreeBSD.ORG Subject: Re: MADV_SEQUENTIAL and GNU Grep Message-ID: <199907291721.KAA75509@apollo.backplane.com> References: <199907291655.JAA29585@lestat.nas.nasa.gov> <199907291659.JAA74615@apollo.backplane.com>
index | next in thread | previous in thread | raw e-mail
Shoot, it barely took 10 minutes for me to move the behavior field from
the object to the vm map entry.
I'm testing it now along with the madvise(... MADV_DONTNEED) changes (to
make them work on files in a reasonable way).
This will be current-only, though I suppose the map changes could be
backported to stable if someone really wanted to.
-Matt
Matthew Dillon
<dillon@backplane.com>
::On Fri, 30 Jul 1999 01:50:28 +0900
:: "Daniel C. Sobral" <dcs@newsguy.com> wrote:
::
:: > Could you please elaborate on "permanent"? To what structure the
:: > information is currently attached, and what, if anything, can make
:: > that structure "go away", short of a reboot?
::
::As permanent as the object ... i.e. as long as the object persists.
::
:: > Of course, we could MADV_NORMAL afterwards, though that would
:: > require changing more than one character. I'm not sure I'm ready for
:: > so much coding... :-)
::
::No, it's not appropriate to work around a kernel bug in this fashion.
::
:: -- Jason R. Thorpe <thorpej@nas.nasa.gov>
:
: I'm willing to fix it. If NetBSD has moved it to the map entry then
: I can move it here without core screaming at me too much, though every
: time I do any work I have to balance the fun against the frustration of
: not being able to commit it myself.
: -Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907291721.KAA75509>