From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964803AbcDYTmx (ORCPT ); Mon, 25 Apr 2016 15:42:53 -0400 Received: from mail-yw0-f171.google.com ([209.85.161.171]:34615 "EHLO mail-yw0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933424AbcDYTmw (ORCPT ); Mon, 25 Apr 2016 15:42:52 -0400 Date: Mon, 25 Apr 2016 15:42:49 -0400 From: Tejun Heo To: Michal Hocko Cc: Johannes Weiner , Petr Mladek , cgroups@vger.kernel.org, Cyril Hrubis , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] memcg: relocate charge moving from ->attach to ->post_attach Message-ID: <20160425194249.GG7822@mtj.duckdns.org> References: <20160413094216.GC5774@pathway.suse.cz> <20160413183309.GG3676@htj.duckdns.org> <20160413192313.GA30260@dhcp22.suse.cz> <20160414175055.GA6794@cmpxchg.org> <20160415191719.GK12583@htj.duckdns.org> <20160417120747.GC21757@dhcp22.suse.cz> <20160421230648.GI4775@htj.duckdns.org> <20160421230902.GJ4775@htj.duckdns.org> <20160425082542.GB23933@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160425082542.GB23933@dhcp22.suse.cz> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Michal. On Mon, Apr 25, 2016 at 10:25:42AM +0200, Michal Hocko wrote: > > * move_charge_struct->mm is added and ->can_attach is now responsible > > for pinning and recording the target mm. mem_cgroup_clear_mc() is > > updated accordingly. This also simplifies mem_cgroup_move_task(). > > > > * mem_cgroup_move_task() is now called from ->post_attach instead of > > ->attach. > > This looks much better than the previous quick&dirty workaround. Thanks > for taking an extra step! > > Sorry for being so pushy but shouldn't we at least document those > callbacks which depend on cgroup_threadgroup_rwsem to never ever block > on WQ directly or indirectly. Maybe even enforce they have to be > non-blocking. This would be out of scope of this particular patch of > course but it would fit nicely into the series. Yeah, I'll look into whether I can annotate this dependency with lockdep. If that isn't doable, I'll document the requirements. cgroup methods have changed a lot and need to be redocumented anyway. Thanks. -- tejun