Andrea Arcangeli wrote:
On Tue, Mar 31, 2009 at 10:09:24AM -0500, Anthony Liguori wrote:
I don't think the registering of ram should be done via sysfs. That would
be a pretty bad interface IMHO. But I do think the functionality that
ksmctl provides along with the security issues I mentioned earlier really
suggest that there ought to be a separate API for control vs. registration
and that control API would make a lot of sense as a sysfs API.
If you wanted to explore alternative APIs for registration, madvise() seems
like the obvious candidate to me.
madvise(start, size, MADV_SHARABLE) seems like a pretty obvious API to me.
madvise to me would sound appropriate, only if ksm would be always-in,
which is not the case as it won't even be built if it's configured to
N.
You can still disable ksm and simply return ENOSYS for the MADV_ flag.
You could even keep it as a module if you liked by separating the
madvise bits from the ksm bits. The madvise() bits could just provide
the tracking infrastructure for determine which vmas were currently
marked as sharable.
You could then have ksm as loadable module that consumed that interface
to then perform scanning.
Besides madvise is sus covered syscall, and this is linux specific detail.
A number of MADV_ flags are Linux specific (like MADV_DOFORK/MADV_DONTFORK).
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html