On Tue, Mar 31, 2009 at 10:54:57AM -0500, Anthony Liguori wrote:
You can still disable ksm and simply return ENOSYS for the MADV_ flag. You
-EINVAL if something, -ENOSYS would tell userland that it shall stop
trying to use madvise, including the other MADV_ too.
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.
What's the point of making ksm a module if one has part of ksm code
loaded in the kernel and not being possible to avoid compiling in?
People that says KSM=N in their .config (like embedded running with 1M
of ram), don't want that tracking overhead compiled into the kernel.
A number of MADV_ flags are Linux specific (like MADV_DOFORK/MADV_DONTFORK).
But those aren't kernel module related, so they're in line with the
standard ones and could be adapted by other OS.
KSM is not a core VM functionality, madvise is a core VM
functionality, so I don't see fit. KSM as ioctl or KSM creating
/proc/<pid>/ksm when loaded, sounds fine to me instead. If open of
either one fails, application won't register in. It's up to you to
choose KSM=M/N, if you want it as core functionality just build as
KSM=Y but leave the option to others to save memory.