Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755244Ab1CWEmo (ORCPT ); Wed, 23 Mar 2011 00:42:44 -0400 Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]:43356 "EHLO fgwmail5.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751861Ab1CWEmn (ORCPT ); Wed, 23 Mar 2011 00:42:43 -0400 X-SecurityPolicyCheck-FJ: OK by FujitsuOutboundMailChecker v1.3.1 Date: Wed, 23 Mar 2011 13:36:14 +0900 From: KAMEZAWA Hiroyuki To: Namhyung Kim Cc: Paul Menage , Li Zefan , containers@lists.linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/3] memcg: move page-freeing code outside of lock Message-Id: <20110323133614.95553de8.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: <1300788417.1492.2.camel@leonhard> References: <1300452855-10194-1-git-send-email-namhyung@gmail.com> <1300452855-10194-3-git-send-email-namhyung@gmail.com> <20110322085938.0691f7f4.kamezawa.hiroyu@jp.fujitsu.com> <1300763079.1483.21.camel@leonhard> <20110322135619.90593f5d.kamezawa.hiroyu@jp.fujitsu.com> <1300788417.1492.2.camel@leonhard> Organization: FUJITSU Co. LTD. X-Mailer: Sylpheed 3.1.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1600 Lines: 48 On Tue, 22 Mar 2011 19:06:57 +0900 Namhyung Kim wrote: > 2011-03-22 (화), 13:56 +0900, KAMEZAWA Hiroyuki: > > On Tue, 22 Mar 2011 12:04:39 +0900 > > Namhyung Kim wrote: > > > > > 2011-03-22 (화), 08:59 +0900, KAMEZAWA Hiroyuki: > > > > On Fri, 18 Mar 2011 21:54:15 +0900 > > > > Namhyung Kim wrote: > > > > > > > > > Signed-off-by: Namhyung Kim > > > > > Cc: KAMEZAWA Hiroyuki > > > > > > > > What is the benefit of this patch ? > > > > > > > > -Kame > > > > > > > > > > Oh, I just thought generally it'd better call such a (potentially) > > > costly function outside of locks and it could reduce few of theoretical > > > contentions between swapons and/or offs. If it doesn't help any > > > realistic cases I don't mind discarding it. > > > > > > > My point is, please write patch description which shows for what this patc is. > > All cleanup are okay to me if it reasonable. But without patch description as > > "this is just a cleanup, no functional change, and the reason is...." > > we cannot maintain patches. > > > > Thanks, > > -Kame > > > > OK, I will do that in the future. Anyway, do you want me to resend the > patch with new description? > please. I'll never ack a patch without description. Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/