Re: [RFC][PATCH 1/1] Expose per-node reclaim and migration to userspace

Nick Piggin
2006-11-29T06:07:28Z

menage@google.com wrote:
> Currently the page migration APIs allow you to migrate pages from
> particular processes, but don't provide a clean and efficient way to
> migrate and/or reclaim memory from individual nodes.

The mechanism for that should probably go in mm/migrate.c, shouldn't
it?

Also, why don't you scan the lru lists of the zones in the node, which
will a) be much more efficient if there are lots of non LRU pages, and
b) allow you to batch the lru lock.

>
> This patch provides:
>
> - an additional parameter to try_to_free_pages() to specify the
> priority at which the reclaim should give up if it doesn't make
> progress

Dang. It would be nice not to export this "priority" stuff outside
vmscan.c too much because it is really an implementation detail and
I would like to get rid of it one day...

>
> - a way to trigger try_to_free_pages() for a given node with a given
> minimum priority, vy writing an integer to
> /sys/device/system/node/node<id>/try_to_free_pages

... especially not to userspace. Why does this have to be exposed to
userspace at all? Can you not wire it up to your resource isolation
implementation in the kernel?

>
> - a way to request that any migratable pages on a given node be
> migrated to availage pages on a specified set of nodes by writing a
> destination nodemask (in ASCII form) to
> /sys/device/system/node/node<id>/migrate_node

... yeah it would obviously be much nicer to do it in kernel space,
behind your higher level APIs. There's probably a good reason why you
aren't, and I haven't been following the lists very much over the
past couple of weeks... Can you describe your problems (or point me
to a post)?

Thanks,
Nick

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com