From owner-freebsd-hackers Fri May 16 09:58:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA08072 for hackers-outgoing; Fri, 16 May 1997 09:58:36 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA08067 for ; Fri, 16 May 1997 09:58:34 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA17413; Fri, 16 May 1997 09:50:05 -0700 From: Terry Lambert Message-Id: <199705161650.JAA17413@phaeton.artisoft.com> Subject: Re: mmap() To: narvi@haldjas.folklore.ee (Narvi) Date: Fri, 16 May 1997 09:50:04 -0700 (MST) Cc: terry@lambert.org, james@westongold.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Narvi" at May 16, 97 11:27:50 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > It would have a cost higher than not doing it (ie: non-zero). Using > > mmap() and then doing sequential I/O is probably a very limited market, > > so John would have to amke a decision to accept the non-0 degradation > > on that basis. > > Well, isn't grep doing the same? Mmap a file and then walk it line by line > and output the line matching the regular expression? Any program that > processes some kind of text file line by line will most probably express > the same kind of access pattern. I don't know. If it is, then you have a good "pro" argument (or a good argument for converting grep to normal buffered file I/O). > I am not sure, but in case of several processes accessing one file using > MADV_WILLNEED / MADV_DONTNEED could perhaps help? The MADV_WILLNEED does not predictively fault, it only predictively maps the pages which are already in core. This is an up-front hit taken in lieu of a statistical hit. It will raise the priority of the in-core pages so mapped, so if they are after the current sequence address, I suppose it makes it more likely that they will stay in core. I could probably mount a nify denial of service attack using this, if I sat down and thought about it for a while with the VM code in front of me. > By the way - in the source of grep, madvise(.. MADV_SEQUENCIAL ..) is > commented for being slover. I will give it a try... You might as well do the code change to the VM and time it, then. We've spent so much time discussing the existing flags and why they don't do what you want that the changes could have already been made and benchmarked. 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.