ZFS ARC under memory pressure

[Karl Denninger]

On 8/21/2016 03:28, Konstantin Belousov wrote:
> On Sat, Aug 20, 2016 at 11:08:44AM -0500, Karl Denninger wrote:
>> If you are talking about the case of an executable in which part of the
>> text is evicted you are correct, however, you are still choosing in that
>> instance to evict a page for which there will likely be a future demand
>> and thus require an I/O (should that executable come back up for
>> execution) as opposed to one for which you have no idea how likely
>> demand for same will be (a data page in the ARC.)
> No, I am not talking about only text segments.
> Any clean page can be reused after unmapping.
And this accounts for pages being evicted to the swap..... how? 
(Obviously they're not simply unmapped, and thus were not "clean" when
targeted by the VM)
>> Since the VM has no means of "coloring" the ARC (as it is opaque other
>> than the consumption of system memory to the VM) as to how "useful"
>> (e.g. how often used, etc) a particular data item in the ARC is, it has
>> no information available on which to decide.  However, the fact that an
>> executing process is in some sort of waiting state still likely trumps
>> an ARC data page in terms of likelihood of future access.
> Buffer cache behaves exactly the same, since access references are not
> counted for the pages constituing buffers.
It is always amusing when I am told how things are supposed to occur
(and thus assumptions that were made when writing code) when I have
spent countless hours observing how they actually do behave and writing
code to mitigate the very behavior that is claimed to not happen.

I should have something for 11-MostlyStable on the original PR's thread
in a couple of weeks, assuming I manage to complete what I'm working on
right now on-schedule.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20160821/12a08308/attachment.bin>