Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II

Paul Jackson
2005-02-21T01:50:19Z

> - Give the shared libraries and any other files a suitable policy
> (by mapping them and applying mbind)

Ah - I think you've said this before, and I'm being a bit retarded.

You're saying that one could horse around with the physical placement of
existing files mapped into another tasks space by mapping them into ones
own space and using mbind, (once mbind is hooked up to page migration,
to quote one of your earlier posts ;). Ok.

How well does this work with a mapped file if the pages of that file
have been placed (allocated on nodes) using some intricate first-touch
pattern that is only encoded in some inscrutable initialization code of
the application, and that is heavily fragmented, with few contiguous
pages on the same node?

It seems to me that you can't migrate such regions efficiently using the
above explicit mbind'ing -- it could require a vma per page in the
limit. And you can't migrate such regions using a migrate_pages() for
all anonymous pages in a tasks space, because these aren't anon pages.

Do you have in mind being able to tag such mapped files with an
attribute that causes their pages to be migrated along with the
anon pages on the migrate_pages() call? That might work ...

> > How would you recommend that the batch manager move that job to the
> > nodes that can run it? ...
>
> You have to walk to full node mapping for each array, but
> even with hundreds of nodes that should not be that costly

I presume if you knew that the job only had pages on certain nodes,
perhaps due to aggressive use of cpusets, that you would only have to
walk those nodes, right?

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