Received: by 10.68.125.233 with SMTP id mt9mr10522777pbb.5.1335570681213;
        Fri, 27 Apr 2012 16:51:21 -0700 (PDT)
Path: r9ni106164pbh.0!nntp.google.com!news2.google.com!goblin1!goblin.stu.neva.ru!uio.no!nntp.uio.no!.POSTED!not-for-mail
From: Hiroyuki Kamezawa <kamezawa.hiroy...@gmail.com>
Newsgroups: fa.linux.kernel
Subject: Re: [RFC][PATCH 3/7 v2] res_counter: add res_counter_uncharge_until()
Date: Fri, 27 Apr 2012 23:51:20 UTC
Organization: Internet mailing list
Lines: 37
Sender: linux-kernel-ow...@vger.kernel.org
Message-ID: <fa.6nqTm1iko1sWuT/XwgGnI8Vx86E@ifi.uio.no>
References: <fa.HAq6f5cQAWH1ZlvOpbbuCmTjXrA@ifi.uio.no> <fa.3fS11hMOntwvdovyKuG3/kgnvc4@ifi.uio.no> <fa.y2lkMBmDFcExeSTiY7hSvvEn1zk@ifi.uio.no>
NNTP-Posting-Host: mail-jess.uio.no
Mime-Version: 1.0
X-Trace: readme.uio.no 1335570680 30694 129.240.7.9 (27 Apr 2012 23:51:20 GMT)
X-Complaints-To: abuse@uio.no
NNTP-Posting-Date: Fri, 27 Apr 2012 23:51:20 +0000 (UTC)
Cc: KAMEZAWA Hiroyuki <kamezawa.hir...@jp.fujitsu.com>,
	Linux Kernel <linux-ker...@vger.kernel.org>,
	"linux...@kvack.org" <linux...@kvack.org>,
	"cgro...@vger.kernel.org" <cgro...@vger.kernel.org>,
	Michal Hocko <mho...@suse.cz>,
	Johannes Weiner <han...@cmpxchg.org>,
	Frederic Weisbecker <fweis...@gmail.com>,
	Tejun Heo <t...@kernel.org>, Han Ying <ying...@google.com>,
	"Aneesh Kumar K.V" <aneesh.ku...@linux.vnet.ibm.com>,
	Andrew Morton <a...@linux-foundation.org>
To: Glauber Costa <glom...@parallels.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        bh=2hGpXhJzzZkRqTs5imN84S+QCSKWsvnFmu8ZH/rMGnY=;
        b=PkEwFsZvF/J//6oUcewAV5OjxrBwQp901m0dNrs0bm2o9nk8L4JxOTTOQf9sdNOQfJ
         ML9kUSfKVkoQpLgbIu7kUTMAEvzl/aJO7DigU3H8485O8xkcQ2NMvvUTtitcqVWNZ1pc
         c1qOZyViKIQK7gcy7GQeyJq5L8DaGLDMMwnlrbnuirlIaUiAaiQRzKfceU23GZCb5z3y
         mt0QzS+6m+4ZWAA/90+I2oHXa1wjMSHvAkyFAvWEJP6Rqu5OiM4pSK3o5kSHtFs+flDv
         RHhFKSD9Y0OShDZ16ah/7hEnLlL5Gn0PG8VyD8D/pvGXYIXIFahFszC6gBx/173/4Ne7
         ofrQ==
In-Reply-To: <4F9AD28C.60...@parallels.com>
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-ker...@vger.kernel.org
Original-Date: Sat, 28 Apr 2012 08:51:11 +0900
Original-Message-Id: <CABEgKgrHXeXX1napajY-hRqDPB1snL1xWmrAVxVKkOGEvnJ...@mail.gmail.com>
Original-References: <4F9A327A.6050...@jp.fujitsu.com>
	<4F9A343F.7020...@jp.fujitsu.com>
	<4F9AD28C.60...@parallels.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT

On Sat, Apr 28, 2012 at 2:08 AM, Glauber Costa <glom...@parallels.com> wrote:
> On 04/27/2012 02:53 AM, KAMEZAWA Hiroyuki wrote:
>>  From bb0168d5c85f62f36434956e4728a67d0cc41e55 Mon Sep 17 00:00:00 2001
>> From: KAMEZAWA Hiroyuki<kamezawa.hir...@jp.fujitsu.com>
>> Date: Thu, 26 Apr 2012 18:48:07 +0900
>> Subject: [PATCH 3/9] memcg: add res_counter_uncharge_until()
>>
>> At killing res_counter which is a child of other counter,
>> we need to do
>>       res_counter_uncharge(child, xxx)
>>       res_counter_charge(parent, xxx)
>>
>> This is not atomic and wasting cpu. This patch adds
>> res_counter_uncharge_until(). This function's uncharge propagates
>> to ancestors until specified res_counter.
>>
>>       res_counter_uncharge_until(child, parent, xxx)
>>
>> This ops is atomic and more efficient.
>>
>> Originaly-written-by: Frederic Weisbecker<fweis...@gmail.com>
>> Signed-off-by: KAMEZAWA Hiroyuki<kamezawa.hir...@jp.fujitsu.com>
> I have been carrying Frederic's patch itself in my code for a while now.
>
> Why not just use it? What are you doing differently to justify writing a
> patch yourself? It's a bit of credit giving as well

I don't need "charge" part for my purpose and have no justification to add it.
And task-limit cgroup has no justification, either.

Thanks,
-Kame
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/