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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]