Re: [RFC v4 PATCH 2/9] mm/hugetlb: expose hugetlb fault mutex for use by fallocate

[Mike Kravetz]

On 06/11/2015 03:46 PM, Davidlohr Bueso wrote:
> On Thu, 2015-06-11 at 14:01 -0700, Mike Kravetz wrote:
> >   /* Forward declaration */
> >   static int hugetlb_acct_memory(struct hstate *h, long delta);
> > @@ -3324,7 +3324,8 @@ static u32 fault_mutex_hash(struct hstate *h, struct mm_struct *mm,
> >   	unsigned long key[2];
> >   	u32 hash;
> >
> > -	if (vma->vm_flags & VM_SHARED) {
> > +	/* !vma implies this was called from hugetlbfs fallocate code */
> > +	if (!vma || vma->vm_flags & VM_SHARED) {
>
> That !vma is icky, and really no need for it: hugetlbfs_fallocate(), for
> example, already passes [pseudo]vma->vm_flags with VM_SHARED, and you
> say it yourself in the comment. Do you see any reason why we cannot just
> keep the vma->vm_flags & VM_SHARED check?
>
> > +/*
> > + * Interface for use by hugetlbfs fallocate code.  Faults must be
> > + * synchronized with page adds or deletes by fallocate.  fallocate
> > + * only deals with shared mappings.  See also hugetlb_fault_mutex_lock
> > + * and hugetlb_fault_mutex_unlock.
> > + */
> > +u32 hugetlb_fault_mutex_shared_hash(struct address_space *mapping, pgoff_t idx)
> > +{
> > +	return fault_mutex_hash(NULL, NULL, NULL, mapping, idx, 0);
> > +}
>
> It strikes me that this too should be static inlined. But I really
> dislike the nil params thing, which should be addressed by my comment
> above.

In the previous RFC, I was trying not to make all the fault mutex data
global (so it could be accessed outside hugetlb.c).  That was the
original reason for the wrapper interfaces.  That may just be too ugly,
and does not buy us much.

Now that the mutex table is global for inlining, I might as well make
fault_mutex_hash() global.  I can then get rid of the wrappers.  However,
I'm guessing it would be a good idea to change the name(s) to something
hugetlb specific since they will be global.

--
Mike Kravetz

> Thanks,
> Davidlohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/