Re: memcg uncharge page counter mismatch

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

 



On Fri, Dec 04, 2015 at 09:52:27AM +0100, Michal Hocko wrote:
> On Fri 04-12-15 14:35:15, Minchan Kim wrote:
> > On Thu, Dec 03, 2015 at 04:47:29PM +0100, Michal Hocko wrote:
> > > On Thu 03-12-15 15:58:50, Michal Hocko wrote:
> > > [....]
> > > > Warning, this looks ugly as hell.
> > > 
> > > I was thinking about it some more and it seems that we should rather not
> > > bother with partial thp at all and keep it in the original memcg
> > > instead. It is way much less code and I do not think this will be too
> > > disruptive. Somebody should be holding the thp head, right?
> > > 
> > > Minchan, does this fix the issue you are seeing.
> > 
> > This patch solves the issue but not sure it's right approach.
> > I think it could make regression that in old, we could charge
> > a THP page but we can't now.
> 
> The page would still get charged when allocated. It just wouldn't get
> moved when mapped only partially. IIUC there will be still somebody
> mapping the THP head via pmd, right? That process will move the page to

If I read code correctly, No. The split_huge_pmd splits just pmd,
not page itself. IOW, it could be possible !pmd_trans_huge(pmd) &&
PageTransHuge although there is only process owns the page.

> the new memcg when moved. Or is it possible that we will end up only
> with pte mapped THP from all processes? Kirill?

I'm not Kirill but I think it's possible.
If so, a thing we can use is page_mapcount(page) == 1. With that,
it could gaurantee only a process owns the page so charge 512 instead of 1?

> 
> If not then I think it is reasonable to expect that partially mapped THP
> is not moved during task migration. I will post an official patch after
> Kirill confirms my understanding.
> 
> Anyway thanks for the testing and pointing me to right direction
> Minchan!

Thanks for the quick patch and feedback, Michal.

> 
> -- 
> Michal Hocko
> SUSE Labs

-- 
Kind regards,
Minchan Kim

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



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