lkml.org 
[lkml]   [2009]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/3] ksm: write protect pages from inside ksm
    Izik Eidus wrote:
    > Izik Eidus wrote:
    >> Hugh Dickins wrote:
    >>> On Sat, 13 Jun 2009, Izik Eidus wrote:
    >>>
    >>>> Hugh, so untill here we are sync,
    >>>>
    >>>
    >>> Yes, that fits with what I have here, thanks (or where it didn't
    >>> quite fit, e.g. ' versus `, I've adjusted to what you have!). And
    >>> thanks for fixing my *orig_pte = *ptep bug, you did point that out
    >>> before, but I misunderstood at first.
    >>>
    >>>
    >>>> Question is what you want me to do now?,
    >>>> (Beacuse we are skipping 2.6.31, It is ok to you to tell me something
    >>>> like: "Shut up and let me see what i can get with this madvise" -
    >>>> that from one side.
    >>>> From another side if you want me to do anything please say.
    >>>>
    >>>
    >>> I had to get a bit further at my end before answering on that,
    >>> but now the answer is clear: please do some testing of your RFC
    >>> madvise() version (which is what I'm just tidying up a little),
    >>> and let me know any bugfixes you find. Try with SLAB or SLUB or
    >>> SLQB debug on e.g. CONFIG_SLUB=y, CONFIG_SLUB_DEBUG=y and boot
    >>> option "slub_debug".
    >>>
    >>
    >> Sure, let me check it.
    >> (You do have Andrea patch that fix the "used after free slab entries" ?)
    >
    > How fast is it crush opps to you?, I compiled it and ran it here on
    > 2.6.30-rc4-mm1 with:
    > "Enable SLQB debugging support" and "SLQB debugging on by default, and
    > it run and merge (i am using qemu processes to run virtual machines to
    > merge the pages between them)
    >
    > ("SLQB debugging on by defaul" mean i dont have to add boot pareameter
    > right?)
    >
    > Maybe i should try update into newer version of the mm tree? (last
    > commit here is Jul 22)

    OK, bug on my side, just got that oppss, will try to fix and send patch.

    (Sorry for the noise)

    >
    >>
    >>> I'm finding, whether with your RFC or my tidyup, that kksmd
    >>> soon oopses in get_next_mmlist (or perhaps find_vma): presumably
    >>> accessing a vma or mm which already got freed (if you don't have
    >>> slab debugging on, it's liable to hang instead).
    >>>
    >>> (I've also not seen it actually merging yet: if you register
    >>> or madvise a large anon area and memset it, the /dev/ksm version
    >>> would merge all its pages, but I've not seen the madvise version
    >>> do so yet - though maybe there's something stupidly wrong in my
    >>> testing, really I'm more worried about the oopses at present.)
    >>>
    >>> Note that mmotm includes a patch of Nick's which adds a function
    >>> madvise_behavior_valid() - you'll need to add your MADVs into its
    >>> list to get it to work at all there.
    >>>
    >>> Here's a patch I added a month or so ago, when trying to experiment
    >>> with KSM on all mms: shouldn't be necessary if your mm refcounting
    >>> is right, but might help to avoid extra weirdness when things go
    >>> wrong: exit_mmap() leaves stale vma pointers around, reckoning
    >>> that nobody can be interested by now; but maybe KSM might peep
    >>> so better to tidy them up at least while debugging...
    >>>
    >>> Thanks,
    >>> Hugh
    >>>
    >>> --- old/mm/mmap.c 2009-05-01 13:47:45.000000000 +0100
    >>> +++ new/mm/mmap.c 2009-05-03 11:34:47.000000000 +0100
    >>> @@ -2112,6 +2112,14 @@ void exit_mmap(struct mm_struct *mm)
    >>> tlb_finish_mmu(tlb, 0, end);
    >>>
    >>> /*
    >>> + * Make sure get_user_pages() and find_vma() etc. will find
    >>> nothing:
    >>> + * this may be necessary for KSM.
    >>> + */
    >>> + mm->mmap = NULL;
    >>> + mm->mmap_cache = NULL;
    >>> + mm->mm_rb = RB_ROOT;
    >>> +
    >>> + /*
    >>> * Walk the list again, actually closing and freeing it,
    >>> * with preemption enabled, without holding any MM locks.
    >>> */
    >>>
    >>
    >>
    >
    >



    \
     
     \ /
      Last update: 2009-06-15 02:07    [W:0.046 / U:119.588 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site