On 04/25/2010 03:41 AM, Dan Magenheimer wrote:
No, ANY put_page can fail, and this is a critical part of the API
that provides all of the flexibility for the hypervisor and all
the guests. (See previous reply.)
The guest isn't required to do any put_page()s. It can issue lots of
them when memory is available, and keep them in the hypervisor forever.
Failing new put_page()s isn't enough for a dynamic system, you need to
be able to force the guest to give up some of its tmem.
Yes, indeed, this is true. That is why it is important for any
policy implemented behind frontswap to "bill" the guest if it
is attempting to keep frontswap pages in the hypervisor forever
and to prod the guest to reclaim them when it no longer needs
super-fast emergency swap space. The frontswap patch already includes
the kernel mechanism to enable this and the prodding can be implemented
by a guest daemon (of which there already exists an existence proof).
In this case you could use the same mechanism to stop new put_page()s?
Seems frontswap is like a reverse balloon, where the balloon is in
hypervisor space instead of the guest space.
(While devil's advocacy is always welcome, frontswap is NOT a
cool academic science project where these issues have not been
considered or tested.)
Good to know.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>