On Tue, Aug 29, 2017 at 09:33:44AM +0900, Joonsoo Kim wrote:

On Mon, Aug 28, 2017 at 03:08:29PM +0200, Michal Hocko wrote:

quoted

On Mon 28-08-17 13:29:29, Vlastimil Babka wrote:

quoted

On 08/28/2017 03:11 AM, js1304@gmail.com wrote:

quoted

From: Joonsoo Kim <redacted>

High-order atomic allocation is difficult to succeed since we cannot
reclaim anything in this context. So, we reserves the pageblock for
this kind of request.

In slub, we try to allocate higher-order page more than it actually
needs in order to get the best performance. If this optimistic try is
used with GFP_ATOMIC, alloc_flags will be set as ALLOC_HARDER and
the pageblock reserved for high-order atomic allocation would be used.
Moreover, this request would reserve the MIGRATE_HIGHATOMIC pageblock
,if succeed, to prepare further request. It would not be good to use
MIGRATE_HIGHATOMIC pageblock in terms of fragmentation management
since it unconditionally set a migratetype to request's migratetype
when unreserving the pageblock without considering the migratetype of
used pages in the pageblock.

This is not what we don't intend so fix it by unconditionally setting
__GFP_NOMEMALLOC in order to not set ALLOC_HARDER.

I wonder if it would be more robust to strip GFP_ATOMIC from alloc_gfp.
E.g. __GFP_NOMEMALLOC does seem to prevent ALLOC_HARDER, but not
ALLOC_HIGH. Or maybe we should adjust __GFP_NOMEMALLOC implementation
and document it more thoroughly? CC Michal Hocko

Yeah, __GFP_NOMEMALLOC is rather inconsistent. It has been added to
override __GFP_MEMALLOC resp. PF_MEMALLOC AFAIK. In this particular
case I would agree that dropping __GFP_HIGH and __GFP_ATOMIC would
be more precise. I am not sure we want to touch the existing semantic of
__GFP_NOMEMALLOC though. This would require auditing all the existing
users (something tells me that quite some of those will be incorrect...)

Hmm... now I realize that there is another reason that we need to use
__GFP_NOMEMALLOC. Even if this allocation comes from PF_MEMALLOC user,
this optimistic try should not use the reserved memory below the
watermark. That is, it should not use ALLOC_NO_WATERMARKS. It can
only be accomplished by using __GFP_NOMEMALLOC.

Michal, Vlastimil, Any thought?

Thanks.

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