From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755503Ab2IXIv1 (ORCPT ); Mon, 24 Sep 2012 04:51:27 -0400 Received: from mx2.parallels.com ([64.131.90.16]:55840 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755328Ab2IXIv0 (ORCPT ); Mon, 24 Sep 2012 04:51:26 -0400 Message-ID: <50601E41.5000603@parallels.com> Date: Mon, 24 Sep 2012 12:48:01 +0400 From: Glauber Costa User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: Tejun Heo CC: , , , , , Suleiman Souhlal , Frederic Weisbecker , Mel Gorman , David Rientjes , Michal Hocko , Johannes Weiner Subject: Re: [PATCH v3 12/13] execute the whole memcg freeing in rcu callback References: <1347977050-29476-1-git-send-email-glommer@parallels.com> <1347977050-29476-13-git-send-email-glommer@parallels.com> <20120921172355.GD7264@google.com> In-Reply-To: <20120921172355.GD7264@google.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > And the above description too makes me scratch my head quite a bit. I > can see what the patch is doing but can't understand the why. > > * Why was it punting the freeing to workqueue anyway? ISTR something > about static_keys but my memory fails. What changed? Why don't we > need it anymore? > > * As for locking context, the above description seems a bit misleading > to me. Synchronization constructs involved there currently doesn't > require softirq or irq safe context. If that needs to change, > that's fine but that's a completely different reason than given > above. > > Thanks. > I just suck at changelogs =( The problem here is very much like the one we had with static branches. In that case, we had the problem with the cgroup_lock() being held, in which case the jump label lock could not be called. In here, after the kmem patches are in, the destruction function could be called directly from memcg_kmem_uncharge_page() when the last put is done. But this can actually be called from the page allocator, with an incompatible softirq context. So it is not that it could be called, they are actually called in that context at this point. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx185.postini.com [74.125.245.185]) by kanga.kvack.org (Postfix) with SMTP id BBD796B002B for ; Mon, 24 Sep 2012 04:51:27 -0400 (EDT) Message-ID: <50601E41.5000603@parallels.com> Date: Mon, 24 Sep 2012 12:48:01 +0400 From: Glauber Costa MIME-Version: 1.0 Subject: Re: [PATCH v3 12/13] execute the whole memcg freeing in rcu callback References: <1347977050-29476-1-git-send-email-glommer@parallels.com> <1347977050-29476-13-git-send-email-glommer@parallels.com> <20120921172355.GD7264@google.com> In-Reply-To: <20120921172355.GD7264@google.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Tejun Heo Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, kamezawa.hiroyu@jp.fujitsu.com, devel@openvz.org, linux-mm@kvack.org, Suleiman Souhlal , Frederic Weisbecker , Mel Gorman , David Rientjes , Michal Hocko , Johannes Weiner > And the above description too makes me scratch my head quite a bit. I > can see what the patch is doing but can't understand the why. > > * Why was it punting the freeing to workqueue anyway? ISTR something > about static_keys but my memory fails. What changed? Why don't we > need it anymore? > > * As for locking context, the above description seems a bit misleading > to me. Synchronization constructs involved there currently doesn't > require softirq or irq safe context. If that needs to change, > that's fine but that's a completely different reason than given > above. > > Thanks. > I just suck at changelogs =( The problem here is very much like the one we had with static branches. In that case, we had the problem with the cgroup_lock() being held, in which case the jump label lock could not be called. In here, after the kmem patches are in, the destruction function could be called directly from memcg_kmem_uncharge_page() when the last put is done. But this can actually be called from the page allocator, with an incompatible softirq context. So it is not that it could be called, they are actually called in that context at this point. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [PATCH v3 12/13] execute the whole memcg freeing in rcu callback Date: Mon, 24 Sep 2012 12:48:01 +0400 Message-ID: <50601E41.5000603@parallels.com> References: <1347977050-29476-1-git-send-email-glommer@parallels.com> <1347977050-29476-13-git-send-email-glommer@parallels.com> <20120921172355.GD7264@google.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120921172355.GD7264-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Tejun Heo Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org, devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Suleiman Souhlal , Frederic Weisbecker , Mel Gorman , David Rientjes , Michal Hocko , Johannes Weiner > And the above description too makes me scratch my head quite a bit. I > can see what the patch is doing but can't understand the why. > > * Why was it punting the freeing to workqueue anyway? ISTR something > about static_keys but my memory fails. What changed? Why don't we > need it anymore? > > * As for locking context, the above description seems a bit misleading > to me. Synchronization constructs involved there currently doesn't > require softirq or irq safe context. If that needs to change, > that's fine but that's a completely different reason than given > above. > > Thanks. > I just suck at changelogs =( The problem here is very much like the one we had with static branches. In that case, we had the problem with the cgroup_lock() being held, in which case the jump label lock could not be called. In here, after the kmem patches are in, the destruction function could be called directly from memcg_kmem_uncharge_page() when the last put is done. But this can actually be called from the page allocator, with an incompatible softirq context. So it is not that it could be called, they are actually called in that context at this point.