GFP_USER, GFP_HIGHUSER and GFP_HIGHUSER_MOVABLE are escalatedly
confined defined, also implied by their names:
GFP_USER = GFP_USER
GFP_USER + __GFP_HIGHMEM = GFP_HIGHUSER
GFP_USER + __GFP_HIGHMEM + __GFP_MOVABLE = GFP_HIGHUSER_MOVABLE
So just make GFP_HIGHUSER and GFP_HIGHUSER_MOVABLE escalatedly defined
to reflect this fact. It also makes the definition clear and texturally
warn on any furture break-up of this escalated relastionship.
Signed-off-by: Jianyu Zhan <[email protected]>
---
include/linux/gfp.h | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 41b30fd..f7c74c8 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -110,11 +110,8 @@ struct vm_area_struct;
#define GFP_TEMPORARY (__GFP_WAIT | __GFP_IO | __GFP_FS | \
__GFP_RECLAIMABLE)
#define GFP_USER (__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HARDWALL)
-#define GFP_HIGHUSER (__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HARDWALL | \
- __GFP_HIGHMEM)
-#define GFP_HIGHUSER_MOVABLE (__GFP_WAIT | __GFP_IO | __GFP_FS | \
- __GFP_HARDWALL | __GFP_HIGHMEM | \
- __GFP_MOVABLE)
+#define GFP_HIGHUSER (GFP_USER | __GFP_HIGHMEM)
+#define GFP_HIGHUSER_MOVABLE (GFP_HIGHUSER | __GFP_MOVABLE)
#define GFP_IOFS (__GFP_IO | __GFP_FS)
#define GFP_TRANSHUGE (GFP_HIGHUSER_MOVABLE | __GFP_COMP | \
__GFP_NOMEMALLOC | __GFP_NORETRY | __GFP_NOWARN | \
--
2.0.0
On Tue, Nov 25, 2014 at 12:43:47AM +0800, Jianyu Zhan wrote:
> GFP_USER, GFP_HIGHUSER and GFP_HIGHUSER_MOVABLE are escalatedly
> confined defined, also implied by their names:
>
> GFP_USER = GFP_USER
> GFP_USER + __GFP_HIGHMEM = GFP_HIGHUSER
> GFP_USER + __GFP_HIGHMEM + __GFP_MOVABLE = GFP_HIGHUSER_MOVABLE
>
> So just make GFP_HIGHUSER and GFP_HIGHUSER_MOVABLE escalatedly defined
> to reflect this fact. It also makes the definition clear and texturally
> warn on any furture break-up of this escalated relastionship.
>
> Signed-off-by: Jianyu Zhan <[email protected]>
Acked-by: Johannes Weiner <[email protected]>
On Tue, Nov 25, 2014 at 12:43:47AM +0800, Jianyu Zhan wrote:
> GFP_USER, GFP_HIGHUSER and GFP_HIGHUSER_MOVABLE are escalatedly
> confined defined, also implied by their names:
>
> GFP_USER = GFP_USER
> GFP_USER + __GFP_HIGHMEM = GFP_HIGHUSER
> GFP_USER + __GFP_HIGHMEM + __GFP_MOVABLE = GFP_HIGHUSER_MOVABLE
Looks reasonable.
Acked-by: Kirill A. Shutemov <[email protected]>
But I would prefer to have GPF_HIGHUSER movable by default and
GFP_HIGHUSER_UNMOVABLE to opt out.
--
Kirill A. Shutemov
On Tue, 25 Nov 2014, Jianyu Zhan wrote:
> GFP_USER, GFP_HIGHUSER and GFP_HIGHUSER_MOVABLE are escalatedly
> confined defined, also implied by their names:
>
> GFP_USER = GFP_USER
> GFP_USER + __GFP_HIGHMEM = GFP_HIGHUSER
> GFP_USER + __GFP_HIGHMEM + __GFP_MOVABLE = GFP_HIGHUSER_MOVABLE
>
> So just make GFP_HIGHUSER and GFP_HIGHUSER_MOVABLE escalatedly defined
> to reflect this fact. It also makes the definition clear and texturally
> warn on any furture break-up of this escalated relastionship.
>
> Signed-off-by: Jianyu Zhan <[email protected]>
Acked-by: David Rientjes <[email protected]>
On Mon, 24 Nov 2014, Kirill A. Shutemov wrote:
> But I would prefer to have GPF_HIGHUSER movable by default and
> GFP_HIGHUSER_UNMOVABLE to opt out.
>
Sounds like a separate patch.
On Mon, Nov 24, 2014 at 01:35:00PM -0800, David Rientjes wrote:
> On Mon, 24 Nov 2014, Kirill A. Shutemov wrote:
>
> > But I would prefer to have GPF_HIGHUSER movable by default and
> > GFP_HIGHUSER_UNMOVABLE to opt out.
> >
>
> Sounds like a separate patch.
There are few questions before preparing patch:
1. Compatibility: some code which is not yet in tree can rely on
non-movable behaviour of GFP_HIGHUSER. How would we handle this?
Should we invent new name for the movable GFP_HIGHUSER?
2. Should GFP_USER be movable too? And the same compatibility question
here.
3. Do we need a separate define for non-movable GPF_HIGHUSER or caller
should use something like GPF_HIGHUSER & ~__GFP_MOVABLE?
4. Is there a gain, taking into account questions above?
--
Kirill A. Shutemov