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

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

 



On Thu 16-05-13 08:28:33, Konstantin Khlebnikov wrote:
> Michal Hocko wrote:
> >On Wed 15-05-13 16:35:08, Konstantin Khlebnikov wrote:
> >>Sha Zhengju wrote:
> >>>Hi,
> >>>
> >>>This is my second attempt to make memcg page stat lock simpler, the
> >>>first version: http://www.spinics.net/lists/linux-mm/msg50037.html.
> >>>
> >>>In this version I investigate the potential race conditions among
> >>>page stat, move_account, charge, uncharge and try to prove it race
> >>>safe of my proposing lock scheme. The first patch is the basis of
> >>>the patchset, so if I've made some stupid mistake please do not
> >>>hesitate to point it out.
> >>
> >>I have a provocational question. Who needs these numbers? I mean
> >>per-cgroup nr_mapped and so on.
> >
> >Well, I guess it makes some sense to know how much page cache and anon
> >memory is charged to the group. I am using that to monitor the per-group
> >memory usage. I can imagine a even better coverage - something
> >/proc/meminfo like.
> >
> 
> I think page counters from lru-vectors can give enough information for that.

not for dirty and writeback data which is the next step.

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

> 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.
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




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

  Powered by Linux