From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933007Ab2EKSBH (ORCPT ); Fri, 11 May 2012 14:01:07 -0400 Received: from mx2.parallels.com ([64.131.90.16]:44974 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932949Ab2EKSBD (ORCPT ); Fri, 11 May 2012 14:01:03 -0400 Message-ID: <4FAD531D.6030007@parallels.com> Date: Fri, 11 May 2012 14:57:49 -0300 From: Glauber Costa User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Christoph Lameter CC: , , , , Tejun Heo , Li Zefan , Greg Thelen , Suleiman Souhlal , Michal Hocko , Johannes Weiner , , Pekka Enberg Subject: Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree References: <1336758272-24284-1-git-send-email-glommer@parallels.com> <1336758272-24284-5-git-send-email-glommer@parallels.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [187.105.248.83] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/11/2012 02:53 PM, Christoph Lameter wrote: > On Fri, 11 May 2012, Glauber Costa wrote: > >> struct page already have this information. If we start chaining >> caches, this information will always be more trustworthy than >> whatever is passed into the function > > Other allocators may not have that information and this patch may > cause bugs to go unnoticed if the caller specifies the wrong slab cache. > > Adding a VM_BUG_ON may be useful to make sure that kmem_cache_free is > always passed the correct slab cache. Well, problem is , it isn't always passed the "correct" slab cache. At least not after this series, since we'll have child caches associated with the main cache. So we'll pass, for instance, kmem_cache_free(dentry_cache...), but will in fact free from the memcg copy of the dentry cache. We can, of course, verify if the cache at least belongs to the same "family". But that's quite expensive. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx134.postini.com [74.125.245.134]) by kanga.kvack.org (Postfix) with SMTP id 749A68D0020 for ; Fri, 11 May 2012 14:01:07 -0400 (EDT) Message-ID: <4FAD531D.6030007@parallels.com> Date: Fri, 11 May 2012 14:57:49 -0300 From: Glauber Costa MIME-Version: 1.0 Subject: Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree References: <1336758272-24284-1-git-send-email-glommer@parallels.com> <1336758272-24284-5-git-send-email-glommer@parallels.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Christoph Lameter Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, kamezawa.hiroyu@jp.fujitsu.com, Tejun Heo , Li Zefan , Greg Thelen , Suleiman Souhlal , Michal Hocko , Johannes Weiner , devel@openvz.org, Pekka Enberg On 05/11/2012 02:53 PM, Christoph Lameter wrote: > On Fri, 11 May 2012, Glauber Costa wrote: > >> struct page already have this information. If we start chaining >> caches, this information will always be more trustworthy than >> whatever is passed into the function > > Other allocators may not have that information and this patch may > cause bugs to go unnoticed if the caller specifies the wrong slab cache. > > Adding a VM_BUG_ON may be useful to make sure that kmem_cache_free is > always passed the correct slab cache. Well, problem is , it isn't always passed the "correct" slab cache. At least not after this series, since we'll have child caches associated with the main cache. So we'll pass, for instance, kmem_cache_free(dentry_cache...), but will in fact free from the memcg copy of the dentry cache. We can, of course, verify if the cache at least belongs to the same "family". But that's quite expensive. -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree Date: Fri, 11 May 2012 14:57:49 -0300 Message-ID: <4FAD531D.6030007@parallels.com> References: <1336758272-24284-1-git-send-email-glommer@parallels.com> <1336758272-24284-5-git-send-email-glommer@parallels.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Christoph Lameter Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org, Tejun Heo , Li Zefan , Greg Thelen , Suleiman Souhlal , Michal Hocko , Johannes Weiner , devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org, Pekka Enberg On 05/11/2012 02:53 PM, Christoph Lameter wrote: > On Fri, 11 May 2012, Glauber Costa wrote: > >> struct page already have this information. If we start chaining >> caches, this information will always be more trustworthy than >> whatever is passed into the function > > Other allocators may not have that information and this patch may > cause bugs to go unnoticed if the caller specifies the wrong slab cache. > > Adding a VM_BUG_ON may be useful to make sure that kmem_cache_free is > always passed the correct slab cache. Well, problem is , it isn't always passed the "correct" slab cache. At least not after this series, since we'll have child caches associated with the main cache. So we'll pass, for instance, kmem_cache_free(dentry_cache...), but will in fact free from the memcg copy of the dentry cache. We can, of course, verify if the cache at least belongs to the same "family". But that's quite expensive.