Re: [PATCH V2 0/3] memcg: simply lock of page stat accounting

[Michal Hocko <mhocko@suse.cz>]

On Fri 17-05-13 09:57:37, Konstantin Khlebnikov wrote:
> Michal Hocko wrote:
> >On Thu 16-05-13 08:28:33, Konstantin Khlebnikov wrote:
[...]
> >>If somebody needs more detailed information there are enough ways to get it.
> >>Amount of mapped pages can be estimated via summing rss counters from mm-structs.
> >>Exact numbers can be obtained via examining /proc/pid/pagemap.
> >
> >How do you find out whether given pages were charged to the group of
> >interest - e.g. shared data or taks that has moved from a different
> >group without move_at_immigrate?
> 
> For example we can export pages ownership and charging state via
> single file in proc, something similar to /proc/kpageflags

So you would like to add a new interface with cryptic api (I consider
kpageflags to be a devel tool not an admin aid) to replace something
that is easy to use? Doesn't make much sense to me.

> BTW
> In our kernel the memory controller tries to change page's ownership
> at first mmap and at each page activation, probably it's worth to add
> this into mainline memcg too.

Dunno, there are different approaches for this. I haven't evalueted them
so I don't know all the pros and cons. Why not just unmap&uncharge the
page when the charging process dies. This should be more lightweight
wrt. recharge on re-activation.
 
> >>I don't think that simulating 'Mapped' line in /proc/mapfile is a worth reason
> >>for adding such weird stuff into the rmap code on map/unmap paths.
> >
> >The accounting code is trying to be not intrusive as much as possible.
> >This patchset makes it more complicated without a good reason and that
> >is why it has been Nacked by me.
> 
> I think we can remove it or replace it with something different but
> much less intrusive, if nobody strictly requires exactly this approach
> in managing 'mapped' pages counters.

Do you have any numbers on the intrusiveness? I do not mind to change
the internal implementation but the file is a part of the user space API
so we cannot get rid of it.
-- 
Michal Hocko
SUSE Labs

--
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>