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

[Avi Kivity <avi@redhat.com>]

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