From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753960AbYJCPP4 (ORCPT ); Fri, 3 Oct 2008 11:15:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752204AbYJCPPs (ORCPT ); Fri, 3 Oct 2008 11:15:48 -0400 Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]:36670 "EHLO fgwmail5.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752156AbYJCPPr (ORCPT ); Fri, 3 Oct 2008 11:15:47 -0400 From: kamezawa.hiroyu@jp.fujitsu.com Message-ID: <2964081.1223046917168.kamezawa.hiroyu@jp.fujitsu.com> Date: Sat, 4 Oct 2008 00:15:17 +0900 (JST) To: Daisuke Nishimura Subject: Re: Re: [PATCH 3/6] memcg: charge-commit-cancel protocl Cc: KAMEZAWA Hiroyuki , nishimura@mxp.nes.nec.co.jp, linux-mm@kvack.org, LKML , balbir@linux.vnet.ibm.com In-Reply-To: <20081003190509.e33a3843.nishimura@mxp.nes.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: @nifty Webmail 2.0 References: <20081003190509.e33a3843.nishimura@mxp.nes.nec.co.jp> <20081001165233.404c8b9c.kamezawa.hiroyu@jp.fujitsu.com> <20081001165734.e484cfe4.kamezawa.hiroyu@jp.fujitsu.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- Original Message ----- >> precharge/commit/cancel can be used for other places, >> - shmem, (and other places need precharge.) >> - move_account(force_empty) etc... >> we'll revisit later. >> >> Changelog v5 -> v6: >> - added newpage_charge() and migrate_fixup(). >> - renamed functions for swap-in from "swap" to "swapin" >> - add more precise description. >> > >I don't have any objection to this direction now, but I have one quiestion. > >Does mem_cgroup_charge_migrate_fixup need to charge a newpage, >while mem_cgroup_prepare_migration has charged it already? In migration-is-failed case, we have to charge *old page* here. > >I agree adding I/F would be good for future, but I think >mem_cgroup_charge_migration_fixup can be no-op function for now. > Hmm, handling failure case in explicit way may be better. Ok, I'll try some. Thanks, -Kame