Re: [Qemu-devel] Re: [Qemu-commits] [COMMIT 3086844] Instead of writing a zero page, madvise it away

[Avi Kivity]

On 06/22/2009 07:58 PM, Anthony Liguori wrote:
> > Note that the patch contains a small bug -- the kernel is allowed to 
> > ignore the advise according to the manual page, so it's better to 
> > memset() the memory before dropping it.
>
>
> Hrm, that's not quite how I interpreted the man page.
>
> "This call
>  does not influence the semantics of the application (except in the case
>  of  MADV_DONTNEED),  but  may influence its performance.  The kernel is
>  free to ignore the advice."
>
> MADV_DONTNEED is called out as changing the application semantics.  
> Specifically, I think the kernel has to zero-fill even if it choose to 
> ignore the advice.
>
> I limited the guard to Linux specifically because I was unsure about 
> that behavior but it would be good to clarify if anyone knows how.

This is not posix (there is a POSIX_MADV_DONTNEED which appears to be 
non-destructive (and a better complement to the other advices)), so the 
only references are the manual page and the code.  I don't see Linux 
ever avoiding brake brake brake the kernel certainly can ignore the advice:

static long madvise_dontneed(struct vm_area_struct * vma,
                 struct vm_area_struct ** prev,
                 unsigned long start, unsigned long end)
{
    *prev = vma;
    if (vma->vm_flags & (VM_LOCKED|VM_HUGETLB|VM_PFNMAP))
        return -EINVAL;

    if (unlikely(vma->vm_flags & VM_NONLINEAR)) {
        struct zap_details details = {
            .nonlinear_vma = vma,
            .last_index = ULONG_MAX,
        };
        zap_page_range(vma, start, end - start, &details);
    } else
        zap_page_range(vma, start, end - start, NULL);
    return 0;
}

it won't do it silently, but we don't check the return code either.  
Let's take the safe path on this and zero the page.

--
error compiling committee.c: too many arguments to function