linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mark Gross <mgross@linux.intel.com>
To: David Rientjes <rientjes@google.com>
Cc: linux-mm@kvack.org, linux-pm@lists.osdl.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	mark.gross@intel.com, neelam.chandwani@intel.com
Subject: Re: [RFC] [PATCH] Power Managed memory base enabling
Date: Tue, 6 Mar 2007 09:20:39 -0800	[thread overview]
Message-ID: <20070306172039.GA26038@linux.intel.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0703060904380.27341@chino.kir.corp.google.com>

On Tue, Mar 06, 2007 at 09:12:06AM -0800, David Rientjes wrote:
> On Tue, 6 Mar 2007, Mark Gross wrote:
> 
> > For the initial version of HW that can do this we are stuck with
> > allocation based decisions where a complete solution needs page
> > migration.
> > 
> > Yes, a sysfs interface is being looked at to export the control to a
> > user mode daemon doing running some kind of policy manager, and if/when
> > page migration happens it will be hooked up to this interface.
> > 
> 
> Is do_migrate_pages() currently unsatisfactory for this?

This looks like it should be good for this application!  How stable is
this?  The next phase of this work is to export the policy interfaces
and hook up the page migration.  I'm somewhat new to the mm code.

Thanks!

> 
> > > > diff -urN -X linux-2.6.20-mm2/Documentation/dontdiff linux-2.6.20-mm2/mm/memory.c linux-2.6.20-mm2-monroe/mm/memory.c
> > > > --- linux-2.6.20-mm2/mm/memory.c	2007-02-23 11:20:40.000000000 -0800
> > > > +++ linux-2.6.20-mm2-monroe/mm/memory.c	2007-03-02 15:15:53.000000000 -0800
> > > > @@ -2882,3 +2882,29 @@
> > > >  	return buf - old_buf;
> > > >  }
> > > >  EXPORT_SYMBOL_GPL(access_process_vm);
> > > > +
> > > > +#ifdef __x86_64__
> > > > +extern int __power_managed_memory_present(void);
> > > > +extern int __power_managed_node(int srat_node);
> > > > +extern int __find_closest_non_pm_node(int nodeid);
> > > > +#else
> > > > +inline int __power_managed_memory_present(void) { return 0};
> > > > +inline int __power_managed_node(int srat_node) { return 0};
> > > > +inline int __find_closest_non_pm_node(int nodeid) { return nodeid};
> > > > +#endif
> > > > +
> > > > +int power_managed_memory_present(void)
> > > > +{
> > > > +	return __power_managed_memory_present();
> > > > +}
> > > > +
> > > > +int power_managed_node(int srat_node)
> > > > +{
> > > > +	return __power_managed_node(srat_node);
> > > > +}
> > > > +
> > > > +int find_closest_non_pm_node(int nodeid)
> > > > +{
> > > > +	return __find_closest_non_pm_node(nodeid);
> > > > +}
> > > > +
> > > 
> > > Probably should reconsider extern declarations in .c files.
> > >
> > 
> > Yeah, but I couldn't think of a better place to put this code or how to
> > make it portable to non x86_64 architectures.  Recommendations gratefully
> > accepted.
> > 
> 
> I would add this to include/asm-x86_64/topology.h:
> 
> 	extern int __power_managed_memory_present(void);
> 	extern int __power_managed_node(int);
> 	extern int __find_closest_non_pm_node(int);
> 	#define power_managed_memory_present()	__power_managed_memory_present()
> 	#define power_managed_node(nid)		__power_managed_node(nid)
> 	#define find_closest_non_pm_node(nid)	__find_closest_non_pm_node(nid)
> 
> and then put the actual functions in arch/x86_64/numa.c.  Then something 
> like this in include/linux/topology.h would probably suffice:
> 
> 	#ifndef find_closest_non_pm_node
> 	#define find_closest_non_pm_node(nid)	do {} while(0)
> 	#endif
> 
> etc.
> 

thanks,

--mgross

--
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>

  reply	other threads:[~2007-03-06 17:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-05 18:18 [RFC] [PATCH] Power Managed memory base enabling Mark Gross
2007-03-06  1:26 ` KAMEZAWA Hiroyuki
2007-03-06 15:54   ` Mark Gross
2007-03-06 15:09 ` David Rientjes
2007-03-06 16:47   ` Mark Gross
2007-03-06 17:12     ` David Rientjes
2007-03-06 17:20       ` Mark Gross [this message]
2007-03-06 17:33         ` David Rientjes
2007-03-07  2:40     ` David Rientjes
2007-03-09 20:53       ` Mark Gross
2007-03-09 21:27         ` David Rientjes
2007-03-09 21:26           ` Mark Gross
2007-03-26 12:48 ` [linux-pm] " Pavel Machek

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=20070306172039.GA26038@linux.intel.com \
    --to=mgross@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-pm@lists.osdl.org \
    --cc=mark.gross@intel.com \
    --cc=neelam.chandwani@intel.com \
    --cc=rientjes@google.com \
    --cc=torvalds@linux-foundation.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).