Re: computing drop-able caches

[Daniel Walker <danielwa@cisco.com>]

[-- Attachment #1: Type: text/plain, Size: 2162 bytes --]

On 01/28/2016 05:03 PM, Daniel Walker wrote:
> On 01/28/2016 03:58 PM, Johannes Weiner wrote:
>> On Thu, Jan 28, 2016 at 03:42:53PM -0800, Daniel Walker wrote:
>>> "Currently there is no way to figure out the droppable pagecache size
>>> from the meminfo output. The MemFree size can shrink during normal
>>> system operation, when some of the memory pages get cached and is
>>> reflected in "Cached" field. Similarly for file operations some of
>>> the buffer memory gets cached and it is reflected in "Buffers" field.
>>> The kernel automatically reclaims all this cached & buffered memory,
>>> when it is needed elsewhere on the system. The only way to manually
>>> reclaim this memory is by writing 1 to /proc/sys/vm/drop_caches. "
>> [...]
>>
>>> The point of the whole exercise is to get a better idea of free 
>>> memory for
>>> our employer. Does it make sense to do this for computing free memory?
>> /proc/meminfo::MemAvailable was added for this purpose. See the doc
>> text in Documentation/filesystem/proc.txt.
>>
>> It's an approximation, however, because this question is not easy to
>> answer. Pages might be in various states and uses that can make them
>> unreclaimable.
>
>
> Khalid was telling me that our internal sources rejected MemAvailable 
> because it was not accurate enough. It says in the description,
> "The estimate takes into account that the system needs some page cache 
> to function well". I suspect that's part of the inaccuracy. I asked 
> Khalid to respond with more details on this.
>

Some quotes,

"
[regarding MemAvaiable]

This new metric purportedly helps usrespace assess available memory. But,
its again based on heuristic, it takes 1/2 of page cache as reclaimable..

Somewhat arbitrary choice. Maybe appropriate for desktops, where page
cache is mainly used as page cache, not as a first class store which is
the case on embedded systems. Our systems are swap less, they have little
secondary storage, they use in-memory databases/filesystems/shared memories/
etc. which are all setup on page caches).. This metric as it is implemented
in 3.14 leads to a totally mis-leading picture of available memory"

Daniel

[-- Attachment #2: Type: text/html, Size: 4737 bytes --]