On 10/28/22 12:13, Peter Xu wrote:
> On Fri, Oct 28, 2022 at 08:23:25AM -0700, Mike Kravetz wrote:
> > On 10/26/22 21:12, Peter Xu wrote:
> > > On Wed, Oct 26, 2022 at 04:54:01PM -0700, Mike Kravetz wrote:
> > > > On 10/26/22 17:42, Peter Xu wrote:
> > diff --git a/mm/madvise.c b/mm/madvise.c
> > index c7105ec6d08c..d8b4d7e56939 100644
> > --- a/mm/madvise.c
> > +++ b/mm/madvise.c
> > @@ -790,7 +790,10 @@ static int madvise_free_single_vma(struct vm_area_struct *vma,
> > static long madvise_dontneed_single_vma(struct vm_area_struct *vma,
> > unsigned long start, unsigned long end)
> > {
> > - zap_page_range(vma, start, end - start);
> > + if (!is_vm_hugetlb_page(vma))
> > + zap_page_range(vma, start, end - start);
> > + else
> > + clear_hugetlb_page_range(vma, start, end);
>
> With the new ZAP_FLAG_UNMAP flag, clear_hugetlb_page_range() can be dropped
> completely? As zap_page_range() won't be with ZAP_FLAG_UNMAP so we can
> identify things?
>
> IIUC that's the major reason why I thought the zap flag could be helpful..
Argh. I went to drop clear_hugetlb_page_range() but there is one issue.
In zap_page_range() the MMU_NOTIFY_CLEAR notifier is certainly called.
However, we really need to have a 'adjust_range_if_pmd_sharing_possible'
call in there because the 'range' may be part of a shared pmd. :(
I think we need to either have a separate routine like clear_hugetlb_page_range
that sets up the appropriate range, or special case hugetlb in zap_page_range.
What do you think?
I think clear_hugetlb_page_range is the least bad of the two options.
--
Mike Kravetz
