From: Pan Xinhui <xinhuix.pan@intel.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
vbabka@suse.cz, rientjes@google.com, hannes@cmpxchg.org,
nasa4836@gmail.com, mgorman@suse.de,
alexander.h.duyck@redhat.com, aneesh.kumar@linux.vnet.ibm.com,
"yanmin_zhang@linux.intel.com" <yanmin_zhang@linux.intel.com>
Subject: Re: [PATCH] gfp: GFP_RECLAIM_MASK should include __GFP_NO_KSWAPD
Date: Wed, 14 Oct 2015 16:17:31 +0800 [thread overview]
Message-ID: <561E0F9B.6090305@intel.com> (raw)
In-Reply-To: <20151014073428.GC28333@dhcp22.suse.cz>
hi, Michal
thanks for your reply :)
On 2015a1'10ae??14ae?JPY 15:34, Michal Hocko wrote:
> On Wed 14-10-15 13:36:51, Pan Xinhui wrote:
>> From: Pan Xinhui <xinhuix.pan@intel.com>
>>
>> GFP_RECLAIM_MASK was introduced in commit 6cb062296f73 ("Categorize GFP
>> flags"). In slub subsystem, this macro controls slub's allocation
>> behavior. In particular, some flags which are not in GFP_RECLAIM_MASK
>> will be cleared. So when slub pass this new gfp_flag into page
>> allocator, we might lost some very important flags.
>>
>> There are some mistakes when we introduce __GFP_NO_KSWAPD. This flag is
>> used to avoid any scheduler-related codes recursive. But it seems like
>> patch author forgot to add it into GFP_RECLAIM_MASK. So lets add it now.
>
> This is no longer needed because GFP_RECLAIM_MASK contains __GFP_RECLAIM
> now - have a look at
> http://lkml.kernel.org/r/1442832762-7247-7-git-send-email-mgorman%40techsingularity.net
> which is sitting in the mmotm tree.
>
I have a look at Mel's patchset. yes, it can help fix my kswapd issue. :)
So I just need change my kmalloc's gfp_flag to GFP_ATOMIC &~ __GFP_KSWAPD_RECLAIM, then slub will not wakeup kswpad.
thanks
xinhui
>> Signed-off-by: Pan Xinhui <xinhuix.pan@intel.com>
>> ---
>> include/linux/gfp.h | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
>> index f92cbd2..9ebad4d 100644
>> --- a/include/linux/gfp.h
>> +++ b/include/linux/gfp.h
>> @@ -130,7 +130,8 @@ struct vm_area_struct;
>> /* Control page allocator reclaim behavior */
>> #define GFP_RECLAIM_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_FS|\
>> __GFP_NOWARN|__GFP_REPEAT|__GFP_NOFAIL|\
>> - __GFP_NORETRY|__GFP_MEMALLOC|__GFP_NOMEMALLOC)
>> + __GFP_NORETRY|__GFP_MEMALLOC|__GFP_NOMEMALLOC|\
>> + __GFP_NO_KSWAPD)
>>
>> /* Control slab gfp mask during early boot */
>> #define GFP_BOOT_MASK (__GFP_BITS_MASK & ~(__GFP_WAIT|__GFP_IO|__GFP_FS))
>> --
>> 1.9.1
>
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Pan Xinhui <xinhuix.pan@intel.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
vbabka@suse.cz, rientjes@google.com, hannes@cmpxchg.org,
nasa4836@gmail.com, mgorman@suse.de,
alexander.h.duyck@redhat.com, aneesh.kumar@linux.vnet.ibm.com,
"yanmin_zhang@linux.intel.com" <yanmin_zhang@linux.intel.com>
Subject: Re: [PATCH] gfp: GFP_RECLAIM_MASK should include __GFP_NO_KSWAPD
Date: Wed, 14 Oct 2015 16:17:31 +0800 [thread overview]
Message-ID: <561E0F9B.6090305@intel.com> (raw)
In-Reply-To: <20151014073428.GC28333@dhcp22.suse.cz>
hi, Michal
thanks for your reply :)
On 2015年10月14日 15:34, Michal Hocko wrote:
> On Wed 14-10-15 13:36:51, Pan Xinhui wrote:
>> From: Pan Xinhui <xinhuix.pan@intel.com>
>>
>> GFP_RECLAIM_MASK was introduced in commit 6cb062296f73 ("Categorize GFP
>> flags"). In slub subsystem, this macro controls slub's allocation
>> behavior. In particular, some flags which are not in GFP_RECLAIM_MASK
>> will be cleared. So when slub pass this new gfp_flag into page
>> allocator, we might lost some very important flags.
>>
>> There are some mistakes when we introduce __GFP_NO_KSWAPD. This flag is
>> used to avoid any scheduler-related codes recursive. But it seems like
>> patch author forgot to add it into GFP_RECLAIM_MASK. So lets add it now.
>
> This is no longer needed because GFP_RECLAIM_MASK contains __GFP_RECLAIM
> now - have a look at
> http://lkml.kernel.org/r/1442832762-7247-7-git-send-email-mgorman%40techsingularity.net
> which is sitting in the mmotm tree.
>
I have a look at Mel's patchset. yes, it can help fix my kswapd issue. :)
So I just need change my kmalloc's gfp_flag to GFP_ATOMIC &~ __GFP_KSWAPD_RECLAIM, then slub will not wakeup kswpad.
thanks
xinhui
>> Signed-off-by: Pan Xinhui <xinhuix.pan@intel.com>
>> ---
>> include/linux/gfp.h | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
>> index f92cbd2..9ebad4d 100644
>> --- a/include/linux/gfp.h
>> +++ b/include/linux/gfp.h
>> @@ -130,7 +130,8 @@ struct vm_area_struct;
>> /* Control page allocator reclaim behavior */
>> #define GFP_RECLAIM_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_FS|\
>> __GFP_NOWARN|__GFP_REPEAT|__GFP_NOFAIL|\
>> - __GFP_NORETRY|__GFP_MEMALLOC|__GFP_NOMEMALLOC)
>> + __GFP_NORETRY|__GFP_MEMALLOC|__GFP_NOMEMALLOC|\
>> + __GFP_NO_KSWAPD)
>>
>> /* Control slab gfp mask during early boot */
>> #define GFP_BOOT_MASK (__GFP_BITS_MASK & ~(__GFP_WAIT|__GFP_IO|__GFP_FS))
>> --
>> 1.9.1
>
next prev parent reply other threads:[~2015-10-14 8:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-14 5:36 [PATCH] gfp: GFP_RECLAIM_MASK should include __GFP_NO_KSWAPD Pan Xinhui
2015-10-14 5:36 ` Pan Xinhui
2015-10-14 5:58 ` Pan Xinhui
2015-10-14 5:58 ` Pan Xinhui
2015-10-14 7:41 ` Michal Hocko
2015-10-14 7:41 ` Michal Hocko
2015-10-14 8:36 ` Pan Xinhui
2015-10-14 8:36 ` Pan Xinhui
2015-10-14 7:34 ` Michal Hocko
2015-10-14 7:34 ` Michal Hocko
2015-10-14 8:17 ` Pan Xinhui [this message]
2015-10-14 8:17 ` Pan Xinhui
2015-10-14 8:38 ` Michal Hocko
2015-10-14 8:38 ` Michal Hocko
2015-10-14 8:40 ` Pan Xinhui
2015-10-14 8:40 ` Pan Xinhui
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=561E0F9B.6090305@intel.com \
--to=xinhuix.pan@intel.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.h.duyck@redhat.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=nasa4836@gmail.com \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
--cc=yanmin_zhang@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.