From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail190.messagelabs.com (mail190.messagelabs.com [216.82.249.51]) by kanga.kvack.org (Postfix) with SMTP id 2B4B66B006A for ; Wed, 2 Sep 2009 20:30:14 -0400 (EDT) Received: from m2.gw.fujitsu.co.jp ([10.0.50.72]) by fgwmail5.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id n830UBk7017487 for (envelope-from kamezawa.hiroyu@jp.fujitsu.com); Thu, 3 Sep 2009 09:30:12 +0900 Received: from smail (m2 [127.0.0.1]) by outgoing.m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 86F8C45DE62 for ; Thu, 3 Sep 2009 09:30:11 +0900 (JST) Received: from s2.gw.fujitsu.co.jp (s2.gw.fujitsu.co.jp [10.0.50.92]) by m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 3EEBE45DE64 for ; Thu, 3 Sep 2009 09:30:11 +0900 (JST) Received: from s2.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id A33F11DB8053 for ; Thu, 3 Sep 2009 09:30:06 +0900 (JST) Received: from ml14.s.css.fujitsu.com (ml14.s.css.fujitsu.com [10.249.87.104]) by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id E7EC61DB803F for ; Thu, 3 Sep 2009 09:30:05 +0900 (JST) Message-ID: In-Reply-To: <661de9470909021302ge86d01s5d107dc2b5cffbc5@mail.gmail.com> References: <20090902.205137.71100180.ryov@valinux.co.jp> <661de9470909021302ge86d01s5d107dc2b5cffbc5@mail.gmail.com> Date: Thu, 3 Sep 2009 09:30:05 +0900 (JST) Subject: Re: a room for blkio-cgroup in struct page_cgroup From: "KAMEZAWA Hiroyuki" MIME-Version: 1.0 Content-Type: text/plain;charset=iso-2022-jp Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org To: Balbir Singh Cc: KAMEZAWA Hiroyuki , Ryo Tsuruta , linux-kernel@vger.kernel.org, dm-devel@redhat.com, containers@lists.linux-foundation.org, virtualization@lists.linux-foundation.org, xen-devel@lists.xensource.com, linux-mm@kvack.org List-ID: Balbir Singh wrote: > 2009/9/2 KAMEZAWA Hiroyuki : >> Ryo Tsuruta wrote: >>> Hi Kamezawa-san, >>> >>> As you wrote before (http://lkml.org/lkml/2009/7/22/65) >>>> To be honest, what I expected in these days for people of blockio >>>> cgroup is like following for getting room for themselves. >>> <> >>>> --- mmotm-2.6.31-Jul16.orig/include/linux/page_cgroup.h >>>> +++ mmotm-2.6.31-Jul16/include/linux/page_cgroup.h >>>> @@ -13,7 +13,7 @@ >>>>  struct page_cgroup { >>>>       unsigned long flags; >>>>       struct mem_cgroup *mem_cgroup; >>>> -     struct page *page; >>>> +     /* block io tracking will use extra unsigned long bytes */ >>>>       struct list_head lru;       /* per cgroup LRU list */ >>>> }; >>> >>> Have you already added a room for blkio_cgroup in struct page_cgroup? >> No. >> > > The diff above is unclear, are you removing struct page from page_cgroup? > I said him "if you want a room, plz get by youself, consider more" And offered this change. http://lkml.org/lkml/2009/7/22/65 you were CC'd. Because page_cgroup's layout is same to memmap, we can use similar function as page_cgroup_to_pfn(), pfn_to_page_cgroup(). And, we don't access page_cgroup->page in fast path. (maybe) But as I wrote, we're busy. I'll not do this until all performance fixes go ahead. Thanks, -Kame -- 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/ . Don't email: email@kvack.org