Re: [PATCH 1/2] huge page private reservation review cleanups

Previous thread: [PATCH 2/2] huge page MAP_NORESERVE review cleanups by Andy Whitcroft on Friday, May 30, 2008 - 12:58 pm. (1 message)

Next thread: 活力健康減重!索取試用包 by vjwfmkqjox on Friday, May 30, 2008 - 12:55 pm. (1 message)
To: Andrew Morton <akpm@...>
Cc: <linux-mm@...>, <linux-kernel@...>, <agl@...>, <wli@...>, <kenchen@...>, <dwg@...>, <andi@...>, Mel Gorman <mel@...>, <dean@...>, <abh@...>, Andy Whitcroft <apw@...>
Date: Friday, May 30, 2008 - 12:58 pm

Create some new accessors for vma private data to cut down on and contain
the casts. Encapsulates the huge and small page offset calculations. Also
adds a couple of VM_BUG_ONs for consistency.

Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
mm/hugetlb.c | 56 +++++++++++++++++++++++++++++++++++++++++++-------------
1 files changed, 43 insertions(+), 13 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 729a830..7a5ac81 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -40,6 +40,26 @@ static int hugetlb_next_nid;
*/
static DEFINE_SPINLOCK(hugetlb_lock);

+/*
+ * Convert the address within this vma to the page offset within
+ * the mapping, in base page units.
+ */
+pgoff_t vma_page_offset(struct vm_area_struct *vma, unsigned long address)
+{
+ return ((address - vma->vm_start) >> PAGE_SHIFT) +
+ (vma->vm_pgoff >> PAGE_SHIFT);
+}
+
+/*
+ * Convert the address within this vma to the page offset within
+ * the mapping, in pagecache page units; huge pages here.
+ */
+pgoff_t vma_pagecache_offset(struct vm_area_struct *vma, unsigned long address)
+{
+ return ((address - vma->vm_start) >> HPAGE_SHIFT) +
+ (vma->vm_pgoff >> (HPAGE_SHIFT - PAGE_SHIFT));
+}
+
#define HPAGE_RESV_OWNER (1UL << (BITS_PER_LONG - 1))
#define HPAGE_RESV_UNMAPPED (1UL << (BITS_PER_LONG - 2))
#define HPAGE_RESV_MASK (HPAGE_RESV_OWNER | HPAGE_RESV_UNMAPPED)
@@ -53,36 +73,48 @@ static DEFINE_SPINLOCK(hugetlb_lock);
* to reset the VMA at fork() time as it is not in use yet and there is no
* chance of the global counters getting corrupted as a result of the values.
*/
+static unsigned long get_vma_private_data(struct vm_area_struct *vma)
+{
+ return (unsigned long)vma->vm_private_data;
+}
+
+static void set_vma_private_data(struct vm_area_struct *vma,
+ unsigned long value)
+{
+ vma->vm_private_data = (void *)value;
+}
+
static unsigned long vma_resv_huge_pages(struct vm_area_struct *vma)
...

To: Andy Whitcroft <apw@...>
Cc: Andrew Morton <akpm@...>, <linux-mm@...>, <linux-kernel@...>, <agl@...>, <wli@...>, <kenchen@...>, <dwg@...>, <andi@...>, <dean@...>, <abh@...>
Date: Saturday, May 31, 2008 - 8:21 am

Things are a bit more readable with the helpers for sure. Thanks for catching

--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--

To: Andy Whitcroft <apw@...>
Cc: <linux-mm@...>, <linux-kernel@...>, <agl@...>, <wli@...>, <kenchen@...>, <dwg@...>, <andi@...>, <mel@...>, <dean@...>, <abh@...>, <apw@...>
Date: Friday, May 30, 2008 - 4:29 pm

On Fri, 30 May 2008 17:58:24 +0100

I'll stage this after Mel's

But I wonder if helpers which manipulate a vma's HPAGE_RESV_MASK

Oh. We already kinda have it. Perhaps vma_resv_huge_pages() should
have called set_vma_resv_flags(). I guess the assertions would have
busted that.

Oh well, whatever.

--

To: Andrew Morton <akpm@...>
Cc: Andy Whitcroft <apw@...>, <linux-mm@...>, <linux-kernel@...>, <agl@...>, <wli@...>, <kenchen@...>, <dwg@...>, <andi@...>, <dean@...>, <abh@...>
Date: Saturday, May 31, 2008 - 9:06 am

There are helpers that do that below. It was suggested that I define a
struct with bit-fields instead but I didn't feel it was much easier to

The assertions as-is would have made that hard all right, but the checks
(particularly the SHARED ones) that are there are really defensive in nature
rather than set in stone. A VM_SHARED mapping could use the flags as well
if there was a good reason for it but I didn't want the helpers to be used

I am currently under the belief that the helpers as-is are
fairly easy to understand, should not interfere badly with the
1GB-and-multi-large-page-support being worked on and are reasonably difficult
to use incorrectly but I'm open to being corrected on it.

Thanks

--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--

Previous thread: [PATCH 2/2] huge page MAP_NORESERVE review cleanups by Andy Whitcroft on Friday, May 30, 2008 - 12:58 pm. (1 message)

Next thread: 活力健康減重!索取試用包 by vjwfmkqjox on Friday, May 30, 2008 - 12:55 pm. (1 message)