Re: manual page migration -- issue list

[Paul Jackson <pj@sgi.com>]

Robin wrote:
> Reading /proc/<pid>maps just scans through the vmas and not the
> address space.

Yes - you're right.

So the number of system calls in your example of a few hours ago, using
your preferred array API, if you include the reads of each tasks
/proc/<pid>/maps file, is about equal to the number of tasks, right?

And I take it that the user code you asked Ray about looks at these
maps files for each of the tasks to be migrated, identifies each
mapped range of each mapped object (mapped file or whatever) and
calculates a fairly minimum set of tasks and virtual address ranges
therein, sufficient to cover all the mapped objects that should
be migrated, thus minimizing the amount of scanning that needs
to be done of individual pages.

And further I take it that you recommend the above described code [to
find a fairly minimum set of tasks and address ranges to scan that will
cover any page of interest] be put in user space, not in the kernel (a
quite reasonable recommendation).

Why didn't your example have some writable private pages?  Wouldn't such
pages be commonplace, and wouldn't they have to be migrated for each
thread, resulting in at least N calls to the new sys_page_migrate()
system call, for N tasks, rather than the 3 calls in your example?

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.650.933.1373, 1.925.600.0401
--
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>