Re: manual page migration -- issue list

[Robin Holt <holt@SGI.com>]

On Wed, Feb 16, 2005 at 02:20:09AM -0800, Paul Jackson wrote:
> The next concern that rises to the top for me was best expressed by Andi:
> >
> > The main reasons for that is that I don't think external
> > processes should mess with virtual addresses of another process.
> > It just feels unclean and has many drawbacks (parsing /proc/*/maps
> > needs complicated user code, racy, locking difficult).  
> > 
> > In kernel space handling full VMs is much easier and safer due to better 
> > locking facilities.
> 
> I share Andi's concerns, but I don't see what to do about this.  Andi's
> recommendations seem to be about memory policies (which guide future
> allocations), and not about migration of already allocated physical
> pages.  So for now at least, his recommendations don't seem like answers
> to me.

If we had the ability to change the vendor provided software to meet
our needs, that would be wonderful.

Unfortunately, most of this type code runs on _MANY_ different OSs and
architectures.  If you could get the NUMA api into everything from AIX
to Windows XP, I think you would have a very good chance of convincing
ISVs to start converting.  Until then, there is no clear win over first
touch for their type of application.

With that in mind, we are left with doing things from the outside in.
Heck, if we could get them to change their code, cpusets would be
irrelavent as well ;)

Thanks,
Robin
--
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>