[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090331171158.GY9137@random.random>
Date: Tue, 31 Mar 2009 19:11:58 +0200
From: Andrea Arcangeli <aarcange@...hat.com>
To: Anthony Liguori <anthony@...emonkey.ws>
Cc: Izik Eidus <ieidus@...hat.com>, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org, linux-mm@...ck.org, avi@...hat.com,
chrisw@...hat.com, riel@...hat.com, jeremy@...p.org,
mtosatti@...hat.com, hugh@...itas.com, corbet@....net,
yaniv@...hat.com, dmonakhov@...nvz.org
Subject: Re: [PATCH 4/4] add ksm kernel shared memory driver.
On Tue, Mar 31, 2009 at 11:51:14AM -0500, Anthony Liguori wrote:
> You have two things here. CONFIG_MEM_SHARABLE and CONFIG_KSM.
> CONFIG_MEM_SHARABLE cannot be a module. If it's set to =n, then
> madvise(MADV_SHARABLE) == -ENOSYS.
Where the part that -ENOSYS tell userland madvise syscall table is
empty, which is obviously not the case, wasn't clear?
> If CONFIG_MEM_SHARABLE=y, then madvise(MADV_SHARABLE) will keep track of
> all sharable memory regions. Independently of that, CONFIG_KSM can be set
> to n,m,y. It depends on CONFIG_MEM_SHARABLE and when it's loaded, it
> consumes the list of sharable vmas.
And what do you gain by creating two config params when only one is
needed other than more pain for the poor user doing make oldconfig and
being asked new zillon of questions that aren't necessary?
> But honestly, CONFIG_MEM_SHARABLE shouldn't a lot of code so I don't see
> why you'd even need to make it configable.
Even if you were to move the registration code in madvise with a
-EINVAL retval if KSM was set to N for embedded, CONFIG_KSM would be
enough: the registration code would be surrounded by CONFIG_KSM_MODULE
|| CONFIG_KSM, just like page_wrprotect/replace_page. This
CONFIG_MEM_SHARABLE in addition to CONFIG_KSM is beyond what can make
sense to me.
> The ioctl() interface is quite bad for what you're doing. You're telling
> the kernel extra information about a VA range in userspace. That's what
The ioctl can be extended to also tell which pid to share without
having to specify VA range, and having the feature inherited by the
child. Not everyone wants to deal with VA.
But my main issue with madvise is that it's core kernel functionality
while KSM clearly is not.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists