On Wed, Nov 15, 2017 at 1:31 AM, Jan Kara [off-list ref] wrote:

On Wed 15-11-17 01:32:16, Yang Shi wrote:

quoted

On 11/14/17 1:39 AM, Michal Hocko wrote:

quoted

On Tue 14-11-17 03:10:22, Yang Shi wrote:

quoted

On 11/9/17 5:54 AM, Michal Hocko wrote:

quoted

[Sorry for the late reply]

On Tue 31-10-17 11:12:38, Jan Kara wrote:

quoted

On Tue 31-10-17 00:39:58, Yang Shi wrote:

[...]

quoted

quoted

I do agree it is not fair and not neat to account to producer rather than
misbehaving consumer, but current memcg design looks not support such use
case. And, the other question is do we know who is the listener if it
doesn't read the events?

So you never know who will read from the notification file descriptor but
you can simply account that to the process that created the notification
group and that is IMO the right process to account to.

Yes, if the creator is de-facto owner which defines the lifetime of
those objects then this should be a target of the charge.

quoted

I agree that current SLAB memcg accounting does not allow to account to a
different memcg than the one of the running process. However I *think* it
should be possible to add such interface. Michal?

We do have memcg_kmem_charge_memcg but that would require some plumbing
to hook it into the specific allocation path. I suspect it uses kmalloc,
right?

Yes.

I took a look at the implementation and the callsites of
memcg_kmem_charge_memcg(). It looks it is called by:

* charge kmem to memcg, but it is charged to the allocator's memcg
* allocate new slab page, charge to memcg_params.memcg

I think this is the plumbing you mentioned, right?

Maybe I have misunderstood, but you are using slab allocator. So you
would need to force it to use a different charging context than current.

Yes.

quoted

I haven't checked deeply but this doesn't look trivial to me.

I agree. This is also what I explained to Jan and Amir in earlier
discussion.

And I also agree. But the fact that it is not trivial does not mean that it
should not be done...

I am currently working on directed or remote memcg charging for a
different usecase and I think that would be helpful here as well.

I have two questions though:

1) Is fsnotify_group the right structure to hold the reference to
target mem_cgroup for charging?
2) Remote charging can trigger an OOM in the target memcg. In this
usecase, I think, there should be security concerns if the events
producer can trigger OOM in the memcg of the monitor. We can either
change these allocations to use __GFP_NORETRY or some new gfp flag to
not trigger oom-killer. So, is this valid concern or am I
over-thinking?

thanks,
Shakeel

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>