[PATCH 0/6] CKRM: Memory controller for CKRM

[PATCH 0/6] CKRM: Memory controller for CKRM

[Chandra Seetharaman]

Hello ckrm-tech members,

Here is the latest CKRM Memory controller patch against the patchset
Gerrit released on 06/22/05.

Changes made since last release of memory controller:
	- added in_interrupt() check in __alloc_pages
	- check pud while migrating pages
	- some typographical errors fixed.
	- Added a todo file to keep track of it in open.

It is tested on i386.

Currently disabled on NUMA.

Hello linux-mm members,

These are set of patches that provides the control of memory under the
CKRM
framework(Details at http://ckrm.sf.net). I eagerly wait for your
feedback/comments/suggestions/concerns etc.,

To All,

I am looking for improvement suggestions
        - to not have a field in the page data structure for the mem
          controller
	- to make vmscan.c cleaner.

--------
Patches are
11-01-mem_base_changes:
        Basic changes to the core kernel to support memory controller.

11-02-mem_base-core:
        To fit in the ckrm framework. No support for guarantee, limit in
	this patch. No config file support also.

11-03-mem_core-limit:
        Support for limit is added.

11-04-mem_limit-guar:
        Support for guarantee is added.

11-05-mem_guar-config:
        Support for few config parameters added.

11-06-mem_config-docs:
        Ofcourse... Documentation.

regards,

chandra

-- 

----------------------------------------------------------------------
    Chandra Seetharaman               | Be careful what you choose....
              - sekharan@us.ibm.com   |      .......you may get it.
----------------------------------------------------------------------


--
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:"aart@kvack.org"> aart@kvack.org </a>

[PATCH 0/6] CKRM: Memory controller for CKRM

[Chandra Seetharaman]

Hello ckrm-tech members,

Here is the latest CKRM Memory controller patch against the patchset Gerrit
released on 05/05/05.

I applied the feedback I got on/off the list. Made few fixes and some
cleanups. Details about the changes are in the appripriate patches.

It is tested on i386.

Currently disabled on NUMA.

Hello linux-mm members,

These are set of patches that provides the control of memory under the CKRM
framework(Details at http://ckrm.sf.net). I eagerly wait for your
feedback/comments/suggestions/concerns etc.,

To All,

I am looking for improvement suggestions
        - to not have a field in the page data structure for the mem
          controller
	- to make vmscan.c cleaner.

--------
Patches are
11-01-mem_base_changes:
        Basic changes to the core kernel to support memory controller.

11-02-mem_base-core:
        To fit in the ckrm framework. No support for guarantee, limit in
	this patch. No config file support also.

11-03-mem_core-limit:
        Support for limit is added.

11-04-mem_limit-guar:
        Support for guarantee is added.

11-05-mem_guar-config:
        Support for few config parameters added.

11-06-mem_config-docs:
        Ofcourse... Documentation.

regards,

chandra


-- 

----------------------------------------------------------------------
    Chandra Seetharaman               | Be careful what you choose....
              - sekharan@us.ibm.com   |      .......you may get it.
----------------------------------------------------------------------
--
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:"aart@kvack.org"> aart@kvack.org </a>

Re: [PATCH 0/6] CKRM: Memory controller for CKRM

[Hirokazu Takahashi]

Hello,

It just looks like that once kswapd moves pages between the active lists
and the inactive lists, the pages happen to belong to the class
to which kswapd belong.

Is this right behavior that you intend?

> Hello ckrm-tech members,
> 
> Here is the latest CKRM Memory controller patch against the patchset Gerrit
> released on 05/05/05.
> 
> I applied the feedback I got on/off the list. Made few fixes and some
> cleanups. Details about the changes are in the appripriate patches.
> 
> It is tested on i386.
> 
> Currently disabled on NUMA.
> 
> Hello linux-mm members,
> 
> These are set of patches that provides the control of memory under the CKRM
> framework(Details at http://ckrm.sf.net). I eagerly wait for your
> feedback/comments/suggestions/concerns etc.,
> 
> To All,
> 
> I am looking for improvement suggestions
>         - to not have a field in the page data structure for the mem
>           controller

What do you think if you make each class owns inodes instead of pages
in the page-cache?

> 	- to make vmscan.c cleaner.


Thanks,
Hirokazu Takahashi.



--
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:"aart@kvack.org"> aart@kvack.org </a>

Re: [PATCH 0/6] CKRM: Memory controller for CKRM

[Chandra Seetharaman]

On Thu, May 19, 2005 at 10:43:25AM +0900, Hirokazu Takahashi wrote:
> Hello,
> 
> It just looks like that once kswapd moves pages between the active lists
> and the inactive lists, the pages happen to belong to the class
> to which kswapd belong.

In refill_inactive_zone()(where pages are moved from active to inactive
list), ckrm_zone(where the page came from) is where the inactive pages are 
moved to.

I don't see how you concluded this. Can you point to the code.

> 
> Is this right behavior that you intend?

certainly not :)
> 
> > Hello ckrm-tech members,
> > 
> > Here is the latest CKRM Memory controller patch against the patchset Gerrit
> > released on 05/05/05.
> > 
> > I applied the feedback I got on/off the list. Made few fixes and some
> > cleanups. Details about the changes are in the appripriate patches.
> > 
> > It is tested on i386.
> > 
> > Currently disabled on NUMA.
> > 
> > Hello linux-mm members,
> > 
> > These are set of patches that provides the control of memory under the CKRM
> > framework(Details at http://ckrm.sf.net). I eagerly wait for your
> > feedback/comments/suggestions/concerns etc.,
> > 
> > To All,
> > 
> > I am looking for improvement suggestions
> >         - to not have a field in the page data structure for the mem
> >           controller
> 
> What do you think if you make each class owns inodes instead of pages
> in the page-cache?
> 
> > 	- to make vmscan.c cleaner.
> 
> 
> Thanks,
> Hirokazu Takahashi.
> 
> 
> 

-- 

----------------------------------------------------------------------
    Chandra Seetharaman               | Be careful what you choose....
              - sekharan@us.ibm.com   |      .......you may get it.
----------------------------------------------------------------------
--
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:"aart@kvack.org"> aart@kvack.org </a>

Re: [PATCH 0/6] CKRM: Memory controller for CKRM

[Hirokazu Takahashi]

Hi Chandra,

> On Thu, May 19, 2005 at 10:43:25AM +0900, Hirokazu Takahashi wrote:
> > Hello,
> > 
> > It just looks like that once kswapd moves pages between the active lists
> > and the inactive lists, the pages happen to belong to the class
> > to which kswapd belong.
> 
> In refill_inactive_zone()(where pages are moved from active to inactive
> list), ckrm_zone(where the page came from) is where the inactive pages are 
> moved to.

Ah, I understood.
You have changed these functions not to call add_page_to_active_list() or
add_page_to_inactive_list() anymore.

Still, there may remain problems that mark_page_accessed() calls
add_page_to_active_list() to move pages between classes.
I guess this isn't good manner since some functions which call
mark_page_accessed(), like unmap_mapping_range_vma() or get_user_pages(),
may refer pages of the other classes.

> I don't see how you concluded this. Can you point to the code.
> 
> > 
> > Is this right behavior that you intend?
> 
> certainly not :)
> > 
> > > Hello ckrm-tech members,
> > > 
> > > Here is the latest CKRM Memory controller patch against the patchset Gerrit
> > > released on 05/05/05.
> > > 
> > > I applied the feedback I got on/off the list. Made few fixes and some
> > > cleanups. Details about the changes are in the appripriate patches.
> > > 
> > > It is tested on i386.
> > > 
> > > Currently disabled on NUMA.
> > > 
> > > Hello linux-mm members,
> > > 
> > > These are set of patches that provides the control of memory under the CKRM
> > > framework(Details at http://ckrm.sf.net). I eagerly wait for your
> > > feedback/comments/suggestions/concerns etc.,
> > > 
> > > To All,
> > > 
> > > I am looking for improvement suggestions
> > >         - to not have a field in the page data structure for the mem
> > >           controller
> > 
> > What do you think if you make each class owns inodes instead of pages
> > in the page-cache?
> > 
> > > 	- to make vmscan.c cleaner.


Thanks,
Hirokazu Takahashi.
--
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:"aart@kvack.org"> aart@kvack.org </a>

Re: [PATCH 0/6] CKRM: Memory controller for CKRM

[Chandra Seetharaman]

On Fri, May 20, 2005 at 02:29:27PM +0900, Hirokazu Takahashi wrote:
> Hi Chandra,
> 
> > On Thu, May 19, 2005 at 10:43:25AM +0900, Hirokazu Takahashi wrote:
> > > Hello,
> > > 
> > > It just looks like that once kswapd moves pages between the active lists
> > > and the inactive lists, the pages happen to belong to the class
> > > to which kswapd belong.
> > 
> > In refill_inactive_zone()(where pages are moved from active to inactive
> > list), ckrm_zone(where the page came from) is where the inactive pages are 
> > moved to.
> 
> Ah, I understood.
> You have changed these functions not to call add_page_to_active_list() or
> add_page_to_inactive_list() anymore.
> 
> Still, there may remain problems that mark_page_accessed() calls
> add_page_to_active_list() to move pages between classes.
> I guess this isn't good manner since some functions which call
> mark_page_accessed(), like unmap_mapping_range_vma() or get_user_pages(),
> may refer pages of the other classes.

You mean these functions are not called in the context of the task that
is in the stack ?

> 
<snip>
> > > > 
> > > > I am looking for improvement suggestions
> > > >         - to not have a field in the page data structure for the mem
> > > >           controller
> > > 
> > > What do you think if you make each class owns inodes instead of pages
> > > in the page-cache?

I think i missed to answer this question in the earlier reply.

do you mean a controller for managing inodes ?
> > > 
> > > > 	- to make vmscan.c cleaner.
> 
> 
> Thanks,
> Hirokazu Takahashi.

-- 

----------------------------------------------------------------------
    Chandra Seetharaman               | Be careful what you choose....
              - sekharan@us.ibm.com   |      .......you may get it.
----------------------------------------------------------------------
--
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:"aart@kvack.org"> aart@kvack.org </a>

Re: [PATCH 0/6] CKRM: Memory controller for CKRM

[Hirokazu Takahashi]

Hi Chandra,

> > > On Thu, May 19, 2005 at 10:43:25AM +0900, Hirokazu Takahashi wrote:
> > > > Hello,
> > > > 
> > > > It just looks like that once kswapd moves pages between the active lists
> > > > and the inactive lists, the pages happen to belong to the class
> > > > to which kswapd belong.
> > > 
> > > In refill_inactive_zone()(where pages are moved from active to inactive
> > > list), ckrm_zone(where the page came from) is where the inactive pages are 
> > > moved to.
> > 
> > Ah, I understood.
> > You have changed these functions not to call add_page_to_active_list() or
> > add_page_to_inactive_list() anymore.
> > 
> > Still, there may remain problems that mark_page_accessed() calls
> > add_page_to_active_list() to move pages between classes.
> > I guess this isn't good manner since some functions which call
> > mark_page_accessed(), like unmap_mapping_range_vma() or get_user_pages(),
> > may refer pages of the other classes.
> 
> You mean these functions are not called in the context of the task that
> is in the stack ?

No, in some cases though it doesn't seem to be serious.

You may take a look at unmap_mapping_range_tree() as an example.
It traverses mapping->i_mmap to find all related vma's to be
unmapped. And get_user_pages() has the parameter that indicates
which process space should be accessed.

Thanks,
Hirokazu Takahashi.
--
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:"aart@kvack.org"> aart@kvack.org </a>

Re: [PATCH 0/6] CKRM: Memory controller for CKRM

[Hirokazu Takahashi]

Hi Chandra,

> > > > > 
> > > > > I am looking for improvement suggestions
> > > > >         - to not have a field in the page data structure for the mem
> > > > >           controller
> > > > 
> > > > What do you think if you make each class owns inodes instead of pages
> > > > in the page-cache?
> 
> I think i missed to answer this question in the earlier reply.
> 
> do you mean a controller for managing inodes ?

Yes, I think it might be another solution though I haven't examined
about it yet.


Thanks,
Hirokazu Takahashi.

--
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:"aart@kvack.org"> aart@kvack.org </a>

Re: [PATCH 0/6] CKRM: Memory controller for CKRM

[Hirokazu Takahashi]

Hi Chandra,

> Here is the latest CKRM Memory controller patch against the patchset Gerrit
> released on 05/05/05.
    (snip)
> These are set of patches that provides the control of memory under the CKRM
> framework(Details at http://ckrm.sf.net). I eagerly wait for your
> feedback/comments/suggestions/concerns etc.,
> 
> To All,
> 
> I am looking for improvement suggestions
>         - to not have a field in the page data structure for the mem
>           controller
> 	- to make vmscan.c cleaner.

I think it's very heavy to move all pages, which are mapped to removing
regions, to new classes every time. It always happens when doing exec()
or exit(), while munmap and closing file don't.
Pages associating with libc.so or text of shells might move around
the all classes.

IMHO, it would be enough to just leave them as they are.
These pages would be released a little later if no class touch them,
or they might be accessed from another class to migrate another
class, or they might reused in the same class.

I feel it's not needed to move these pages in hurry.
I prefer the implementation light.
What do you think?


BTW, the memory controller would be a good new to video streaming
guys, I guess.


Thanks,
Hirokazu Takahashi.

--
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:"aart@kvack.org"> aart@kvack.org </a>

Re: [PATCH 0/6] CKRM: Memory controller for CKRM

[Chandra Seetharaman]

On Fri, May 20, 2005 at 06:26:24PM +0900, Hirokazu Takahashi wrote:
> Hi Chandra,
> 
> 
> I think it's very heavy to move all pages, which are mapped to removing
> regions, to new classes every time. It always happens when doing exec()
> or exit(), while munmap and closing file don't.
> Pages associating with libc.so or text of shells might move around
> the all classes.
> 
> IMHO, it would be enough to just leave them as they are.
> These pages would be released a little later if no class touch them,
> or they might be accessed from another class to migrate another
> class, or they might reused in the same class.

No, it will be incorrect, as the class that is using the page doesn't need
these pages anymore, we should not be charging them for those pages.

May be we should do something light while keeping the accounting proper.
Any ideas ?
> 
> I feel it's not needed to move these pages in hurry.
> I prefer the implementation light.
> What do you think?
> 
> 
> BTW, the memory controller would be a good new to video streaming
> guys, I guess.
> 
> 
> Thanks,
> Hirokazu Takahashi.
> 

-- 

----------------------------------------------------------------------
    Chandra Seetharaman               | Be careful what you choose....
              - sekharan@us.ibm.com   |      .......you may get it.
----------------------------------------------------------------------
--
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:"aart@kvack.org"> aart@kvack.org </a>

Re: [PATCH 0/6] CKRM: Memory controller for CKRM

[Hirokazu Takahashi]

Hi Chandra,

> > I think it's very heavy to move all pages, which are mapped to removing
> > regions, to new classes every time. It always happens when doing exec()
> > or exit(), while munmap and closing file don't.
> > Pages associating with libc.so or text of shells might move around
> > the all classes.
> > 
> > IMHO, it would be enough to just leave them as they are.
> > These pages would be released a little later if no class touch them,
> > or they might be accessed from another class to migrate another
> > class, or they might reused in the same class.
> 
> No, it will be incorrect, as the class that is using the page doesn't need
> these pages anymore, we should not be charging them for those pages.
> 
> May be we should do something light while keeping the accounting proper.
> Any ideas ?

I understand your intention. But I don't think it's always proper.
It wouldn't be bad idea to leave pages for perl scripts launched
by Apache, as they may be reused soon.
Each class may tend to re-execute the same programs.

OTOH, pages as a cache of closed file may not be reused by the same
class again, though they're counted as valid pages for the class.

I guess both of them are in gray area.

> > I feel it's not needed to move these pages in hurry.
> > I prefer the implementation light.
> > What do you think?
> > 
> > 
> > BTW, the memory controller would be a good new to video streaming
> > guys, I guess.


Thanks,
Hirokazu Takahashi.
--
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:"aart@kvack.org"> aart@kvack.org </a>

[PATCH 0/6] CKRM: Memory controller for CKRM

[Chandra Seetharaman]

Hello ckrm-tech members,

Here is the latest CKRM Memory controller patch against the patchset Gerrit
released couple of days back.

I applied the feedback I got on/off the list.

It is tested on i386.

Hello linux-mm members,

These are set of patches that provides the control of memory under the CKRM
framework(Details at http://ckrm.sf.net). I eagerly wait for your
feedback/comments/suggestions/concerns etc.,

To All,

I am looking for improvement suggestions
        - to not have a field in the page data structure for the mem
          controller
	- to make vmscan.c cleaner.

--------
Patches are
11-01-mem_base_changes:
        Basic changes to the core kernel to support memory controller.

11-02-mem_base-core:
        To fit in the ckrm framework. No support for guarantee, limit in
this
        patch. No config file support also.

11-03-mem_core-limit:
        Support for limit is added.

11-04-mem_limit-guar:
        Support for guarantee is added.

11-05-mem_guar-config:
        Support for few config parameters added.

11-06-mem_config-docs:
        Ofcourse... Documentation.

regards,

chandra


-- 

----------------------------------------------------------------------
    Chandra Seetharaman               | Be careful what you choose....
              - sekharan@us.ibm.com   |      .......you may get it.
----------------------------------------------------------------------
--
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:"aart@kvack.org"> aart@kvack.org </a>