All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: "hugh@veritas.com" <hugh@veritas.com>,
	"yamamoto@valinux.co.jp" <yamamoto@valinux.co.jp>,
	taka@valinux.co.jp, Andi Kleen <ak@suse.de>,
	"nickpiggin@yahoo.com.au" <nickpiggin@yahoo.com.au>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [RFC][PATCH] radix-tree based page_cgroup. [0/7] introduction
Date: Mon, 25 Feb 2008 08:54:25 +0530	[thread overview]
Message-ID: <47C234E9.3060303@linux.vnet.ibm.com> (raw)
In-Reply-To: <20080225120758.27648297.kamezawa.hiroyu@jp.fujitsu.com>

KAMEZAWA Hiroyuki wrote:
> This patch series is for implementing radix-tree based page_cgroup.
> 
> This patch does
>   - remove page_cgroup member from struct page.
>   - add a lookup function get_page_cgroup(page).
> 
> And, by removing page_cgroup member, we'll have to change the whole lock rule.
> In this patch, page_cgroup is allocated on demand but not freed. (see TODO).
> 
> This is first trial and I hope I get advices, comments.
> 
> 
> Following is unix bench result under ia64/NUMA box, 8 cpu system. 
> (Shell Script 8 concurrent result was not available from unknown reason.)
> ./Run fstime execl shell C hanoi
> 
> == rc2 + CONFIG_CGROUP_MEM_CONT ==
> File Read 1024 bufsize 2000 maxblocks    937399.0 KBps  (30.0 secs, 3 samples)
> File Write 1024 bufsize 2000 maxblocks   323117.0 KBps  (30.0 secs, 3 samples)
> File Copy 1024 bufsize 2000 maxblocks    233737.0 KBps  (30.0 secs, 3 samples)
> Execl Throughput                           2418.7 lps   (29.7 secs, 3 samples)
> Shell Scripts (1 concurrent)               5506.0 lpm   (60.0 secs, 3 samples)
> Shell Scripts (16 concurrent)               988.3 lpm   (60.0 secs, 3 samples)
> C Compiler Throughput                       741.7 lpm   (60.0 secs, 3 samples)
> Recursion Test--Tower of Hanoi            74555.8 lps   (20.0 secs, 3 samples)
> 
> == rc2 + CONFIG_CGROUP_MEM_CONT + radix-tree based page_cgroup ==
> File Read 1024 bufsize 2000 maxblocks    966342.0 KBps  (30.0 secs, 2 samples)
> File Write 1024 bufsize 2000 maxblocks   316999.0 KBps  (30.0 secs, 2 samples)
> File Copy 1024 bufsize 2000 maxblocks    234167.0 KBps  (30.0 secs, 2 samples)
> Execl Throughput                           2410.5 lps   (29.8 secs, 2 samples)
> Shell Scripts (1 concurrent)               5505.0 lpm   (60.0 secs, 2 samples)
> Shell Scripts (8 concurrent)               1824.5 lpm   (60.0 secs, 2 samples)
> Shell Scripts (16 concurrent)               987.0 lpm   (60.0 secs, 2 samples)
> C Compiler Throughput                       742.5 lpm   (60.0 secs, 2 samples)
> Recursion Test--Tower of Hanoi            74335.6 lps   (20.0 secs, 2 samples)
> 

Hi, KAMEZAWA-San,

The results look quite good.

> looks good as first result.
> 
> Becaue today's my machine time is over, I post this now. I'll rebase this to
> rc3 and reflect comments in the next trial.
> 
> series of patches
> [1/8] --- defintions of header file. 
> [2/8] --- changes in charge/uncharge path and remove locks.
> [3/8] --- changes in page_cgroup_move_lists()
> [4/8] --- changes in page migration with page_cgroup
> [5/8] --- changes in force_empty
> [6/8] --- radix-tree based page_cgroup
> [7/8] --- (Optional) per-cpu fast lookup helper
> [8/8] --- (Optional) Use vmalloc for 64bit machines.
> 
> 
> TODO
>  - Move to -rc3 or -mm ?

I think -mm is better, since we have been pushing all the patches through -mm
and that way we'll get some testing before the patches go in as well.

>  - This patch series doesn't implement page_cgroup removal.
>    I consider it's worth tring to remove page_cgroup when the page is used for
>    HugePage or the page is offlined. But this will incease complexity. So, do later.

Why don't we remove the page_cgroup, what is the increased complexity? I'll take
a look into the patches.

>  - More perfomance measurement and brush codes up.
>  - Check lock dependency...Do more test.

I think we should work this out as well. Hugh is working on cleanup for locking
right now. I suspect that with the radix tree changes, there might a conflict
between your and hugh's work. I think for the moment, while we stabilize and get
the radix tree patches ready, we should get Hugh's cleanup in.

>  - Should I add smaller chunk size for page_cgroup ?
> 
> Thanks,
> -Kame
> 


-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2008-02-25  3:29 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-25  3:07 [RFC][PATCH] radix-tree based page_cgroup. [0/7] introduction KAMEZAWA Hiroyuki
2008-02-25  3:10 ` [RFC][PATCH] radix-tree based page_cgroup. [1/7] definitions for page_cgroup KAMEZAWA Hiroyuki
2008-02-25  7:47   ` Hirokazu Takahashi
2008-02-25  7:56     ` Balbir Singh
2008-02-25  8:03     ` KAMEZAWA Hiroyuki
2008-02-26  7:46       ` Hirokazu Takahashi
2008-02-26  9:07         ` KAMEZAWA Hiroyuki
2008-02-25  3:12 ` [RFC][PATCH] radix-tree based page_cgroup. [2/7] charge/uncharge KAMEZAWA Hiroyuki
2008-02-25  3:13 ` [RFC][PATCH] radix-tree based page_cgroup. [3/7] move lists KAMEZAWA Hiroyuki
2008-02-25  3:14 ` [RFC][PATCH] radix-tree based page_cgroup. [4/7] migration KAMEZAWA Hiroyuki
2008-02-25  3:16 ` [RFC][PATCH] radix-tree based page_cgroup. [5/7] force_empty KAMEZAWA Hiroyuki
2008-02-25  3:17 ` [RFC][PATCH] radix-tree based page_cgroup. [6/7] radix-tree based page cgroup KAMEZAWA Hiroyuki
2008-02-25  5:56   ` YAMAMOTO Takashi
2008-02-25  6:07     ` KAMEZAWA Hiroyuki
2008-02-25  6:40   ` Hirokazu Takahashi
2008-02-25  6:52     ` KAMEZAWA Hiroyuki
2008-02-25  7:05       ` Hirokazu Takahashi
2008-02-25  7:25         ` KAMEZAWA Hiroyuki
2008-02-25  8:02           ` Hirokazu Takahashi
2008-02-25  8:11             ` KAMEZAWA Hiroyuki
2008-02-25  8:28             ` KAMEZAWA Hiroyuki
2008-02-25  3:18 ` [RFC][PATCH] radix-tree based page_cgroup. [7/7] per cpu fast lookup KAMEZAWA Hiroyuki
2008-02-25  5:36   ` YAMAMOTO Takashi
2008-02-25  5:46     ` KAMEZAWA Hiroyuki
2008-02-26 13:26   ` minchan Kim
2008-02-26 13:31     ` minchan Kim
2008-02-26 23:37     ` KAMEZAWA Hiroyuki
2008-02-27  0:57       ` minchan Kim
2008-02-27  1:09         ` KAMEZAWA Hiroyuki
2008-02-27  1:21           ` minchan Kim
2008-02-25  3:19 ` [RFC][PATCH] radix-tree based page_cgroup. [8/7] vmalloc for large machines KAMEZAWA Hiroyuki
2008-02-25  7:06   ` KAMEZAWA Hiroyuki
2008-02-25  3:24 ` Balbir Singh [this message]
2008-02-25  4:02   ` [RFC][PATCH] radix-tree based page_cgroup. [0/7] introduction KAMEZAWA Hiroyuki
2008-02-25  3:31 ` KAMEZAWA Hiroyuki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47C234E9.3060303@linux.vnet.ibm.com \
    --to=balbir@linux.vnet.ibm.com \
    --cc=ak@suse.de \
    --cc=hugh@veritas.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=taka@valinux.co.jp \
    --cc=yamamoto@valinux.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.