On Tue 26-01-21 10:56:54, Mike Rapoport wrote:

On Tue, Jan 26, 2021 at 08:31:42AM +0100, Michal Hocko wrote:

quoted

On Mon 25-01-21 23:38:17, Mike Rapoport wrote:

quoted

On Mon, Jan 25, 2021 at 05:54:51PM +0100, Michal Hocko wrote:

quoted

On Thu 21-01-21 14:27:20, Mike Rapoport wrote:

quoted

From: Mike Rapoport <redacted>

Account memory consumed by secretmem to memcg. The accounting is updated
when the memory is actually allocated and freed.

What does this mean?

That means that the accounting is updated when secretmem does cma_alloc()
and cma_relase().

quoted

What are the lifetime rules?

Hmm, what do you mean by lifetime rules?

OK, so let's start by reservation time (mmap time right?) then the
instantiation time (faulting in memory). What if the calling process of
the former has a different memcg context than the later. E.g. when you
send your fd or inherited fd over fork will move to a different memcg.

What about freeing path? E.g. when you punch a hole in the middle of
a mapping?

Please make sure to document all this.

 
So, does something like this answer your question:

---
The memory cgroup is charged when secremem allocates pages from CMA to
increase large pages pool during ->fault() processing.

OK so that is when the memory is faulted in. Good that is a standard
model we have. The memcg context of the creator of the secret memory is
not really important. So whoever has created is not charged.

The pages are uncharged from memory cgroup when they are released back to
CMA at the time secretme inode is evicted.
---

so effectivelly when they are unmapped, right? This is similar to
anonymous memory.

As I've said it would be really great to have this life cycle documented
properly.

quoted

Please note that this all is a user visible stuff that will become PITA
(if possible) to change later on. You should really have strong
arguments in your justification here.

I think that adding a dedicated counter for few 2M areas per container is
not worth the churn. 

What kind of churn you have in mind? What is the downside?

When we'll get to the point that secretmem can be used to back the entire
guest memory we can add a new counter and it does not seem to PITA to me.

What does really prevent a larger use with this implementation?

-- 
Michal Hocko
SUSE Labs