Re: [patch] mm, memcg: provide a stat to describe reclaimable memory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi David,

David Rientjes writes:
With the proposed anon_reclaimable, do you have any reliability concerns?
This would be the amount of lazy freeable memory and memory that can be
uncharged if compound pages from the deferred split queue are split under
memory pressure.  It seems to be a very precise value (as slab_reclaimable
already in memory.stat is), so I'm not sure why there is a reliability
concern.  Maybe you can elaborate?

Ability to reclaim a page is largely about context at the time of reclaim. For example, if you are running at the edge of swap, at a metric that truly describes "reclaimable memory" will contain vastly different numbers from one second to the next as cluster and page availability increases and decreases. We may also have to do things like look for youngness at reclaim time, so I'm not convinced metrics like this makes sense in the general case.

Today, this information is indeed possible to calculate from userspace.
The idea is to present this information that will be backwards compatible,
however, as the kernel implementation changes.  When lazy freeable memory
was added, for instance, userspace likely would not have preemptively been
doing an "active_file + inactive_file - file" calculation to factor that
in as reclaimable anon :)

I agree it's hard to calculate from userspace without assistance, but I also generally think generally exposing a highly nuanced and situational value to userspace is a recipe for confusion. The user either knows mm internals and can understand it, or don't and probably only misunderstand it. There is a non-zero cognitive cost to adding more metrics like this, which is why I'm interested in knowing more about the userspace usage semantics intended :-)

The example I gave earlier in the thread showed how dramatically different
memory.current is before and after the introduction of deferred split
queues.  Userspace sees ballooning memcg usage and alerts on it (suspects
a memory leak, for example) when in reality this is purely reclaimable
memory under pressure and is the result of a kernel implementation detail.

Again, I'm curious why this can't be solved by artificial workingset pressurisation and monitoring. Generally, the most reliable reclaim metrics come from operating reclaim itself.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux