lkml.org 
[lkml]   [2008]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/4] add ksm kernel shared memory driver
[Let's see if I can get through the rest without premature sends...]

On Wed, 12 Nov 2008 00:17:39 +0200
Izik Eidus <ieidus@redhat.com> wrote:

> > Actually, it occurs to me that there's no sanity checks on any of
> > the values passed in by ioctl(). What happens if the user tells
> > KSM to scan a bogus range of memory?
> >
>
> Well get_user_pages() run in context of the process, therefore it
> should fail in "bogus range of memory"

But it will fail in a totally silent and mysterious way. Doesn't it
seem better to verify the values when you can return a meaningful error
code to the caller?

The other ioctl() calls have the same issue; you can start the thread
with nonsensical values for the number of pages to scan and the sleep
time.

>
> > Any benchmarks on the runtime cost of having KSM running?
> >
>
> This one is problematic, ksm can take anything from 0% to 100% cpu
> its all depend on how fast you run it.
> it have 3 parameters:
> number of pages to scan before it go to sleep
> maximum number of pages to merge while we scanning the above pages
> (merging is expensive)
> time to sleep (when runing from userspace using /dev/ksm, we actually
> do it there (userspace)

What about things like cache effects from scanning all those pages? My
guess is that, if you're trying to run dozens of Windows guests, cache
usage is not at the top of your list of concerns, but I could be
wrong. Usually am...

Thanks,

jon


\
 
 \ /
  Last update: 2008-11-11 23:33    [W:0.070 / U:0.904 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site