On 11/30/22 16:01, Peter Xu wrote:
> On Fri, Oct 21, 2022 at 04:36:22PM +0000, James Houghton wrote:
> > This allows us to add more data into the shared structure, which we will
> > use to store whether or not HGM is enabled for this VMA or not, as HGM
> > is only available for shared mappings.
> >
> > It may be better to include HGM as a VMA flag instead of extending the
> > VMA lock structure.
> >
> > Signed-off-by: James Houghton <jthoughton@xxxxxxxxxx>
> > ---
> > include/linux/hugetlb.h | 4 +++
> > mm/hugetlb.c | 65 +++++++++++++++++++++--------------------
> > 2 files changed, 37 insertions(+), 32 deletions(-)
> >
> > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> > index a899bc76d677..534958499ac4 100644
> > --- a/include/linux/hugetlb.h
> > +++ b/include/linux/hugetlb.h
> > @@ -121,6 +121,10 @@ struct hugetlb_vma_lock {
> > struct vm_area_struct *vma;
> > };
> >
> > +struct hugetlb_shared_vma_data {
> > + struct hugetlb_vma_lock vma_lock;
> > +};
>
> How about add a comment above hugetlb_vma_lock showing how it should be
> used correctly? We lacked documents on the lock for pmd sharing
> protections, now if to reuse the same lock for HGM pgtables I think some
> doc will definitely help.
>
> To summarize, I think so far it means:
>
> - Read lock needed when one wants to stablize VM_SHARED pgtables (covers
> both pmd shared pgtables or hgm low-level pgtables)
>
> - Write lock needed when one wants to release VM_SHARED pgtable pages
> (covers both pmd unshare or releasing hgm low-level pgtables)
Peter must have read ahead and knows that you plan to use the vma_lock for HGM.
The commit message implies that a you only need some type of indication (a flag
for instance) that HGM is enabled for the vma.
No objections to expanding the structure as is done here.
If this is the direction we take, and someday this is extended to private
mappings we could used the same scheme to expand the reserve map structure.
--
Mike Kravetz
