I have a semi-theoretical question about the following code in arc.c,
arc_reclaim_needed() function:
/*
* take 'desfree' extra pages, so we reclaim sooner, rather than later
*/
extra = desfree;
/*
* check that we're out of range of the pageout scanner. It starts to
* schedule paging if freemem is less than lotsfree and needfree.
* lotsfree is the high-water mark for pageout, and needfree is the
* number of needed free pages. We add extra pages here to make sure
* the scanner doesn't start up while we're freeing memory.
*/
if (freemem < lotsfree + needfree + extra)
return (1);
If I understand correctly, there is no pageout (page daemon is idle) until
freemem goes below lotsfree + needfree.
So, let's suppose that there is a "slow eating" userland application such that
each time that page scheduler and ARC reclaim thread check freemem its value is
in the range from lotsfree + needfree to lotsfree + needfree + extra.
This would mean that there would be no paging, but ARC reclaim thread would
reduce ARC size and free up some pages.
Then the application would eat into those pages again and so on, until ARC size
would reach its minimum value.
I think that such an outcome would be undesirable, because in my opinion all
memory consumers should cooperate in freeing / paging out memory when memory
shortage arises.
So, do I am miss anything in ARC code or OpenSolaris VM code that would prevent
the described scenario from taking place?
If not, then why 'extra' was added to the condition in question?
I really would like to understand interaction between VM behavior and ARC sizing
in OpenSolaris.
Thank you very much for any help!
--
Andriy Gapon
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
