linux-kernel - Re: [PATCH] Cgroup: Fix memory accounting scalability in shrink_page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120720151216.GB1426@cmpxchg.org>
Date:	Fri, 20 Jul 2012 17:12:16 +0200
From:	Johannes Weiner <hannes@...xchg.org>
To:	Michal Hocko <mhocko@...e.cz>
Cc:	Tim Chen <tim.c.chen@...ux.intel.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mel@....ul.ie>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Minchan Kim <minchan@...nel.org>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	"andi.kleen" <andi.kleen@...el.com>, linux-mm <linux-mm@...ck.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Cgroup: Fix memory accounting scalability in
 shrink_page_list

On Fri, Jul 20, 2012 at 04:38:48PM +0200, Michal Hocko wrote:
> On Fri 20-07-12 16:16:25, Johannes Weiner wrote:
> > On Fri, Jul 20, 2012 at 03:53:29PM +0200, Michal Hocko wrote:
> > > On Thu 19-07-12 16:34:26, Tim Chen wrote:
> > > [...]
> > > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > > index 33dc256..aac5672 100644
> > > > --- a/mm/vmscan.c
> > > > +++ b/mm/vmscan.c
> > > > @@ -779,6 +779,7 @@ static unsigned long shrink_page_list(struct list_head *page_list,
> > > >  
> > > >  	cond_resched();
> > > >  
> > > > +	mem_cgroup_uncharge_start();
> > > >  	while (!list_empty(page_list)) {
> > > >  		enum page_references references;
> > > >  		struct address_space *mapping;
> > > 
> > > Is this safe? We have a scheduling point few lines below. What prevents
> > > from task move while we are in the middle of the batch?
> > 
> > The batch is accounted in task_struct, so moving a batching task to
> > another CPU shouldn't be a problem.
> 
> But it could also move to a different group, right?

The batch-uncharging task will remember the memcg of the first page it
processes, then pile every subsequent page belonging to the same memcg
on top.  It doesn't matter which group the task is in.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/