OpenVZ Forum - RDF feed
type: channel
items: Re: [PATCH 04/10] memcg: Introduce __GFP_NOACCOUNT.

Re: [PATCH 04/10] memcg: Introduce __GFP_NOACCOUNT.
type: item
description: On 03/03/2012 01:38 PM, Suleiman Souhlal wrote: > On Sat, Mar 3, 2012 at 6:22 AM, Glauber Costa<glommer@parallels.com> wrote: >> On 03/01/2012 03:05 AM, KAMEZAWA Hiroyuki wrote: >>> >>> On Wed, 29 Feb 2012 21:24:11 -0300 >>> Glauber Costa<glommer@parallels.com> wrote: >>> >>>> On 02/29/2012 09:10 PM, KAMEZAWA Hiroyuki wrote: >>>>> >>>>> On Wed, 29 Feb 2012 11:09:50 -0800 >>>>> Suleiman Souhlal<suleiman@google.com> wrote: >>>>> >>>>>> On Tue, Feb 28, 2012 at 10:00 PM, KAMEZAWA Hiroyuki >>>>>> <kamezawa.hiroyu@jp.fujitsu.com> wrote: >>>>>>> >>>>>>> On Mon, 27 Feb 2012 14:58:47 -0800 >>>>>>> Suleiman Souhlal<ssouhlal@FreeBSD.org> wrote: >>>>>>> >>>>>>>> This is used to indicate that we don't want an allocation to be >>>>>>>> accounted >>>>>>>> to the current cgroup. >>>>>>>> >>>>>>>> Signed-off-by: Suleiman Souhlal<suleiman@google.com> >>>>>>> >>>>>>> >>>>>>> I don't like this. >>>>>>> >>>>>>> Please add >>>>>>> >>>>>>> ___GFP_ACCOUNT "account this allocation to memcg" >>>>>>> >>>>>>> Or make this as slab's flag if this work is for slab allocation. >>>>>> >>>>>> >>>>>> We would like to account for all the slab allocations that happen in >>>>>> process context. >>>>>> >>>>>> Manually marking every single allocation or kmem_cache with a GFP flag >>>>>> really doesn't seem like the right thing to do.. >>>>>> >>>>>> Can you explain why you don't like this flag? >>>>>> >>>>> >>>>> For example, tcp buffer limiting has another logic for buffer size >>>>> controling. >>>>> _AND_, most of kernel pages are not reclaimable at all. >>>>> I think you should start from reclaimable caches as dcache, icache etc. >>>>> >>>>> If you want to use this wider, you can discuss >>>>> >>>>> + #define GFP_KERNEL (.....| ___GFP_ACCOUNT) >>>>> >>>>> in future. I'd like to see small start because memory allocation failure >>>>> is always terrible and make the system unstable. Even if you notify >>>>> "Ah, kernel memory allocation failed because of memory.limit? and >>>>> many unreclaimable memory …
creator: Glauber Costa
date: 2012-03-03T23:24:10-00:00

Re: [PATCH 04/10] memcg: Introduce __GFP_NOACCOUNT.
type: item
description: On Sat, Mar 3, 2012 at 3:24 PM, Glauber Costa <glommer@parallels.com> wrote: > On 03/03/2012 01:38 PM, Suleiman Souhlal wrote: >> Another possible example might be the skb data, which are just kmalloc >> and are already accounted by your TCP accounting changes, so we might >> not want to account them a second time. > > > How so? > > struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask, > int fclone, int node) > { > [ ... ] > cache = fclone ? skbuff_fclone_cache : skbuff_head_cache; > > /* Get the HEAD */ > skb = kmem_cache_alloc_node(cache, gfp_mask & ~__GFP_DMA, node); Just a few lines below: data = kmalloc_node_track_caller(size, gfp_mask, node); -- Suleiman
creator: Suleiman Souhlal
date: 2012-03-04T00:10:34-00:00