Re: [RFC][PATCH] page->mapping clarification [1/3] base functions

2007-09-26 Thread KAMEZAWA Hiroyuki
On Wed, 26 Sep 2007 20:31:02 +0100 (BST) Hugh Dickins <[EMAIL PROTECTED]> wrote: > Would that waste a little memory? I think not with SLUB, > but perhaps with SLOB, which packs a little tighter. > maybe just depends on the amount of used anon_vma and page_mapping_info etc... I don't think a syst

Re: [RFC][PATCH] page->mapping clarification [1/3] base functions

2007-09-26 Thread Hugh Dickins
On Sat, 22 Sep 2007, KAMEZAWA Hiroyuki wrote: > On Fri, 21 Sep 2007 18:02:47 +0100 (BST) > Hugh Dickins <[EMAIL PROTECTED]> wrote: > > > Or should I now leave PG_swapcache as is, > > given your designs on page->mapping? > > > will conflict with my idea ? > == > http://marc.info/?l=linux-mm&m=118

Re: [RFC][PATCH] page->mapping clarification [1/3] base functions

2007-09-21 Thread KAMEZAWA Hiroyuki
On Fri, 21 Sep 2007 18:02:47 +0100 (BST) Hugh Dickins <[EMAIL PROTECTED]> wrote: > > 3. I want to *try* page->mapping overriding... store memory resource > > controller's > >information in page->mapping. By this, memory controller doesn't enlarge > > sizeof > >struct page. (works well

Re: [RFC][PATCH] page->mapping clarification [1/3] base functions

2007-09-21 Thread Hugh Dickins
On Fri, 21 Sep 2007, KAMEZAWA Hiroyuki wrote: > On Thu, 20 Sep 2007 11:26:47 -0700 (PDT) > Christoph Lameter <[EMAIL PROTECTED]> wrote: > > > > I am still a bit confused as to what the benefit of this is. > > > Honestly, I have 3 purposes, 2 for readability/clarificaton and 1 for my > trial. >

Re: [RFC][PATCH] page->mapping clarification [1/3] base functions

2007-09-21 Thread KAMEZAWA Hiroyuki
On Fri, 21 Sep 2007 13:48:28 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > Followings are moved > > * page_mapping() ... returns swapper_space or address_space a page > > is on. > > (from mm.h) > > * page_index() ... returns position of a page in its

Re: [RFC][PATCH] page->mapping clarification [1/3] base functions

2007-09-21 Thread Peter Zijlstra
On Wed, 19 Sep 2007 16:43:08 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote: > A clarification of page <-> fs interface (page cache). > > At first, each FS has to access to struct page->mapping directly. > But it's not just pointer. (we use special 1bit enconding for anon.) > > Although there

Re: [RFC][PATCH] page->mapping clarification [1/3] base functions

2007-09-20 Thread KAMEZAWA Hiroyuki
On Thu, 20 Sep 2007 11:26:47 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]> wrote: > On Wed, 19 Sep 2007, KAMEZAWA Hiroyuki wrote: > > > Any comments are welcome. > > I am still a bit confused as to what the benefit of this is. > Honestly, I have 3 purposes, 2 for readability/clarificaton an

Re: [RFC][PATCH] page->mapping clarification [1/3] base functions

2007-09-20 Thread Christoph Lameter
On Wed, 19 Sep 2007, KAMEZAWA Hiroyuki wrote: > Any comments are welcome. I am still a bit confused as to what the benefit of this is. > Following functions are added > > * page_mapping_cache() ... returns address space if a page is page cache > * page_mapping_anon() ... returns anon_vma if

[RFC][PATCH] page->mapping clarification [1/3] base functions

2007-09-19 Thread KAMEZAWA Hiroyuki
Rebased to 2.6.23-rc6-mm1 and reflected comments. Not so aggresive as previous version. (I'm not in a hurry if -mm is busy.) Any comments are welcome. Thanks, -Kame == A clarification of page <-> fs interface (page cache). At first, each FS has to access to struct page->mapping directly. But it'