On 2015/06/04 22:02, Xishi Qiu wrote:
This patch introduces a new gfp flag called "__GFP_MIRROR", it is used to
allocate mirrored pages through buddy system.

Signed-off-by: Xishi Qiu <qiuxi...@huawei.com>

In Tony's original proposal, the motivation was to mirror all kernel memory.

Is the purpose of this patch making mirrored range available for user space ?

But, hmm... I don't think adding a new GFP flag is a good idea. It adds many 
conditional jumps.

How about using GFP_KERNEL for user memory if the user wants mirrored memory 
with mirroring
all kernel memory?

Thanks,
-Kame

---
  include/linux/gfp.h | 5 ++++-
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 15928f0..89d0091 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -35,6 +35,7 @@ struct vm_area_struct;
  #define ___GFP_NO_KSWAPD      0x400000u
  #define ___GFP_OTHER_NODE     0x800000u
  #define ___GFP_WRITE          0x1000000u
+#define ___GFP_MIRROR          0x2000000u
  /* If the above are modified, __GFP_BITS_SHIFT may need updating */

  /*
@@ -95,13 +96,15 @@ struct vm_area_struct;
  #define __GFP_OTHER_NODE ((__force gfp_t)___GFP_OTHER_NODE) /* On behalf of 
other node */
  #define __GFP_WRITE   ((__force gfp_t)___GFP_WRITE)   /* Allocator intends to 
dirty page */

+#define __GFP_MIRROR   ((__force gfp_t)___GFP_MIRROR)  /* Allocate mirrored 
memory */
+
  /*
   * This may seem redundant, but it's a way of annotating false positives vs.
   * allocations that simply cannot be supported (e.g. page tables).
   */
  #define __GFP_NOTRACK_FALSE_POSITIVE (__GFP_NOTRACK)

-#define __GFP_BITS_SHIFT 25    /* Room for N __GFP_FOO bits */
+#define __GFP_BITS_SHIFT 26    /* Room for N __GFP_FOO bits */
  #define __GFP_BITS_MASK ((__force gfp_t)((1 << __GFP_BITS_SHIFT) - 1))

  /* This equals 0, but use constants in case they ever change */



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

Reply via email to