Date: Thu, 15 May 1997 16:13:59 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: james@westongold.com (James Mansion) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: mmap() Message-ID: <199705152313.QAA16073@phaeton.artisoft.com> In-Reply-To: <337B51FA.52F9@westongold.com> from "James Mansion" at May 15, 97 07:12:10 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Maybe you can convince John Dyson that coding this would be fun (it > > might even actually *be* fun 8-)), and then checking the degradation > > this causes in the general case to see if it's unacceptably high for > > your special case. > > I can't see that this would be a high cost. You'd only tell the real > benefit on a loaded system anyway. 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. I'm not saying that it's unlikely, only that there *is* a trade involved, and so a decision tobe made. > Could you even use the simpler and hugely kludgy approach of 'if the > faulting process' descriptor has sequential access, then fault the next > <n> pages' where <n> is some tunable value? This would lead to bursty operation without high and low watermarks... and you are back to storing the last page for that compare. > Factor 2 degradation seems a big hit, particularly when using a > technique that 'should' be efficient, but maybe this would be cheap > and remove much of the performance hit? Well, it's a "not doing an optimization" hit, not a "doing something wrong hit". Frankly, sequentially accessing mmap()'ed data is... wierd. 8-). Like I said, best bet is to talk to John (or do it yourself). > The technique you mention is more along the lines of one that one might > use for cases where the MADV_SEQUENTIAL 'hint' has NOT been given and > you still want a heuristic to identify when sequential access is > nevertheless occuring locally, as might be the case with (say) a DBMS. Yes. > In this case, the hint is plainly given and you might act on it more > directly. Yes again; but you then add a compare for the hint, and still need to save the last value, and compare it if the hint is set. I guess it saves you the save in the general case. Really, I think the hit is negligible; however, it's not my decision to make, no matter what. I'm just suggesting possible approaches to the problem. > What happens for executable image pages? Do those get any readahead > now? No. You'd think data pages, would, though. Datapage might benefit from this optimization as well, so you may be able to sell it that way. It's just that your case is odd, so it's not likely to attract a lot of effort to optimize. I'd suggest you make the changes yourself, if you can, and then see what it does as far as performance. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705152313.QAA16073>