In message <20050223161403.GC11666@spathi.chuq.com>, Chuck Silvers writes:
>> Are there yet more corner cases?  Is there any way to use a cheap
>> conservative test that says a page definitely *is* safe for read
>> loanout, rather than enumerating all the cases when it isn't safe
>> (and potentially missing some)?
>
>enumerating the cases where it's illegal is all we can do.
>in this case, the issue is with the pages being replaced
>rather than the pages being loaned.

OK, Fair enough. I'm just worried about getting this 100% correct at
short notice, and in avoiding any unexpected performance degradation.


>> Also: I assume it's benign, but have you to confirmed by testing that
>> read()ing through files much larger than physical memory isn't
>> penalized by the changes for loanout?
>
>my initial mail gave results for reading a file that wasn't already
>in the cache, which is basically the same as what you're talking about.
>
>but I ran your case just now anyway, reading through 2GB of a file
>on a machine with 512MB of RAM, using the same two buffer sizes as
>before (4KB and 1MB):

... the numbers are a wash (loanout has about a 0.5% win.) Great.

I thought about this more last night. What about an app which writes
into each loaned-out page? Do we take a copy-on-write fault for each
such page? What do the numbers look like then --- that is, is the
penalty bad enough that it's worth adding a per-fd flag to disable
loanout, for apps which intend to dirty their just-read() pages?