lkml.org 
[lkml]   [2009]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/4] add ksm kernel shared memory driver.
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


\
 
 \ /
  Last update: 2009-03-31 17:59    [W:0.466 / U:1.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site