From: Hanjun Guo <guohanjun@huawei.com>
To: "Christoph Lameter (Open Source)" <cl@linux.com>
Cc: Wu Jianguo <wujianguo@huawei.com>,
Jiang Liu <jiang.liu@huawei.com>, Tony Luck <tony.luck@intel.com>,
Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>,
Mel Gorman <mgorman@suse.de>, Yinghai Lu <yinghai@kernel.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
David Rientjes <rientjes@google.com>,
Minchan Kim <minchan@kernel.org>,
Keping Chen <chenkeping@huawei.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Jiang Liu <liuj97@gmail.com>
Subject: Re: [RFC PATCH] mm: introduce N_LRU_MEMORY to distinguish between normal and movable memory
Date: Tue, 14 Aug 2012 19:56:02 +0800 [thread overview]
Message-ID: <502A3CD2.9000007@huawei.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1208100909410.3903@greybox.home>
On 2012/8/10 22:12, Christoph Lameter (Open Source) wrote:
> On Fri, 10 Aug 2012, Hanjun Guo wrote:
>
>> On 2012/8/9 22:06, Christoph Lameter (Open Source) wrote:
>>> On Thu, 9 Aug 2012, Hanjun Guo wrote:
>>>
>>>> Now, We have node masks for both N_NORMAL_MEMORY and
>>>> N_HIGH_MEMORY to distinguish between normal and highmem on platforms such as x86.
>>>> But we still don't have such a mechanism to distinguish between "normal" and "movable"
>>>> memory.
>>>
>>> What is the exact difference that you want to establish?
>>
>> Hi Christoph,
>> Thanks for your comments very much!
>>
>> We want to identify the node only has ZONE_MOVABLE memory.
>> for example:
>> node 0: ZONE_DMA, ZONE_DMA32, ZONE_NORMAL--> N_LRU_MEMORY, N_NORMAL_MEMORY
>> node 1: ZONE_MOVABLE --> N_LRU_MEMORY
>> thus, in SLUB allocator, will not allocate memory control structures for node1.
>
> So this would change the N_NORMAL_MEMORY definition so that N_NORMAL
> means !LRU allocs possible? So far N_NORMAL_MEMORY has a wider scope of
> meaning. We need an accurate definition of the meaning of all these
> attributes.
Hi Christoph,
Sorry for the late reply.
yes, N_LRU_MEMORY means LRU allocs possible,
N_NORMAL_MEMORY means !LRU allocs possible.
node with ZONE_DMA/ZONE_DMA32/ZONE_NORMAL is marked with N_LRU_MEMORY and N_NORMAL_MEMORY,
node with ZONE_MOVABLE is *only* marked with N_LRU_MEMORY.
>
>>> For the slab case that you want to solve here you will need to know if the
>>> node has *only* movable memory and will never have any ZONE_NORMAL memory.
>>> If so then memory control structures for allocators that do not allow
>>> movable memory will not need to be allocated for these node. The node can
>>> be excluded from handling.
>>
>> I think this is what we are trying to do in this patch.
>> did I miss something?
>
> THe meaning of ZONE_NORMAL seems to change which causes confusion. Please
> describe in detail what each of these attributes mean.
>
> .
>
--
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: Hanjun Guo <guohanjun@huawei.com>
To: "Christoph Lameter (Open Source)" <cl@linux.com>
Cc: Wu Jianguo <wujianguo@huawei.com>,
Jiang Liu <jiang.liu@huawei.com>, Tony Luck <tony.luck@intel.com>,
Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>,
Mel Gorman <mgorman@suse.de>, Yinghai Lu <yinghai@kernel.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
David Rientjes <rientjes@google.com>,
Minchan Kim <minchan@kernel.org>,
Keping Chen <chenkeping@huawei.com>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>, Jiang Liu <liuj97@gmail.com>
Subject: Re: [RFC PATCH] mm: introduce N_LRU_MEMORY to distinguish between normal and movable memory
Date: Tue, 14 Aug 2012 19:56:02 +0800 [thread overview]
Message-ID: <502A3CD2.9000007@huawei.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1208100909410.3903@greybox.home>
On 2012/8/10 22:12, Christoph Lameter (Open Source) wrote:
> On Fri, 10 Aug 2012, Hanjun Guo wrote:
>
>> On 2012/8/9 22:06, Christoph Lameter (Open Source) wrote:
>>> On Thu, 9 Aug 2012, Hanjun Guo wrote:
>>>
>>>> Now, We have node masks for both N_NORMAL_MEMORY and
>>>> N_HIGH_MEMORY to distinguish between normal and highmem on platforms such as x86.
>>>> But we still don't have such a mechanism to distinguish between "normal" and "movable"
>>>> memory.
>>>
>>> What is the exact difference that you want to establish?
>>
>> Hi Christoph,
>> Thanks for your comments very much!
>>
>> We want to identify the node only has ZONE_MOVABLE memory.
>> for example:
>> node 0: ZONE_DMA, ZONE_DMA32, ZONE_NORMAL--> N_LRU_MEMORY, N_NORMAL_MEMORY
>> node 1: ZONE_MOVABLE --> N_LRU_MEMORY
>> thus, in SLUB allocator, will not allocate memory control structures for node1.
>
> So this would change the N_NORMAL_MEMORY definition so that N_NORMAL
> means !LRU allocs possible? So far N_NORMAL_MEMORY has a wider scope of
> meaning. We need an accurate definition of the meaning of all these
> attributes.
Hi Christoph,
Sorry for the late reply.
yes, N_LRU_MEMORY means LRU allocs possible,
N_NORMAL_MEMORY means !LRU allocs possible.
node with ZONE_DMA/ZONE_DMA32/ZONE_NORMAL is marked with N_LRU_MEMORY and N_NORMAL_MEMORY,
node with ZONE_MOVABLE is *only* marked with N_LRU_MEMORY.
>
>>> For the slab case that you want to solve here you will need to know if the
>>> node has *only* movable memory and will never have any ZONE_NORMAL memory.
>>> If so then memory control structures for allocators that do not allow
>>> movable memory will not need to be allocated for these node. The node can
>>> be excluded from handling.
>>
>> I think this is what we are trying to do in this patch.
>> did I miss something?
>
> THe meaning of ZONE_NORMAL seems to change which causes confusion. Please
> describe in detail what each of these attributes mean.
>
> .
>
next prev parent reply other threads:[~2012-08-14 11:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1344482788-4984-1-git-send-email-guohanjun@huawei.com>
2012-08-09 4:39 ` [RFC PATCH] mm: introduce N_LRU_MEMORY to distinguish between normal and movable memory Hanjun Guo
2012-08-09 4:39 ` Hanjun Guo
2012-08-09 14:06 ` Christoph Lameter (Open Source)
2012-08-09 14:06 ` Christoph Lameter (Open Source)
2012-08-10 8:48 ` Hanjun Guo
2012-08-10 8:48 ` Hanjun Guo
2012-08-10 14:12 ` Christoph Lameter (Open Source)
2012-08-10 14:12 ` Christoph Lameter (Open Source)
2012-08-14 11:56 ` Hanjun Guo [this message]
2012-08-14 11:56 ` Hanjun Guo
2012-08-14 14:14 ` Christoph Lameter
2012-08-14 14:14 ` Christoph Lameter
2012-08-16 8:19 ` Hanjun Guo
2012-08-16 8:19 ` Hanjun Guo
2012-08-10 9:43 ` Yasuaki Ishimatsu
2012-08-10 9:43 ` Yasuaki Ishimatsu
2012-08-10 12:21 ` Jiang Liu
2012-08-10 12:21 ` Jiang Liu
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=502A3CD2.9000007@huawei.com \
--to=guohanjun@huawei.com \
--cc=chenkeping@huawei.com \
--cc=cl@linux.com \
--cc=jiang.liu@huawei.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liuj97@gmail.com \
--cc=mgorman@suse.de \
--cc=minchan@kernel.org \
--cc=mpm@selenic.com \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=tony.luck@intel.com \
--cc=wujianguo@huawei.com \
--cc=yinghai@kernel.org \
/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.