From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
To: Dave Hansen <dave.hansen@intel.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc: mhocko@suse.com, vbabka@suse.cz, mgorman@suse.de,
minchan@kernel.org, aneesh.kumar@linux.vnet.ibm.com,
bsingharora@gmail.com, srikar@linux.vnet.ibm.com,
haren@linux.vnet.ibm.com, jglisse@redhat.com
Subject: Re: [RFC 1/4] mm: Define coherent device memory node
Date: Wed, 30 Nov 2016 17:16:04 +0530 [thread overview]
Message-ID: <583EBBFC.7090700@linux.vnet.ibm.com> (raw)
In-Reply-To: <692074f0-184f-e506-40a1-8fc078d1e706@intel.com>
On 11/29/2016 11:27 PM, Dave Hansen wrote:
> On 11/22/2016 06:19 AM, Anshuman Khandual wrote:
>> @@ -393,6 +393,9 @@ enum node_states {
>> N_MEMORY = N_HIGH_MEMORY,
>> #endif
>> N_CPU, /* The node has one or more cpus */
>> +#ifdef CONFIG_COHERENT_DEVICE
>> + N_COHERENT_DEVICE,
>> +#endif
>> NR_NODE_STATES
>> };
>
> Don't we really want this to be N_MEMORY_ISOLATED? Or, better yet,
Sure, If we move from a CDM description to a purely node isolation one.
I am still thinking through this.
> N_MEMORY_UNISOLATED so that we can just drop the bitmap in for N_MEMORY
Did not get that, N_MEMORY_UNISOLATED for the system RAM nodes which are
not isolated ? Then where the isolated/CDM nodes go in ?
> and not have to do any bit manipulation operations at runtime.
>
--
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: Anshuman Khandual <khandual@linux.vnet.ibm.com>
To: Dave Hansen <dave.hansen@intel.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc: mhocko@suse.com, vbabka@suse.cz, mgorman@suse.de,
minchan@kernel.org, aneesh.kumar@linux.vnet.ibm.com,
bsingharora@gmail.com, srikar@linux.vnet.ibm.com,
haren@linux.vnet.ibm.com, jglisse@redhat.com
Subject: Re: [RFC 1/4] mm: Define coherent device memory node
Date: Wed, 30 Nov 2016 17:16:04 +0530 [thread overview]
Message-ID: <583EBBFC.7090700@linux.vnet.ibm.com> (raw)
In-Reply-To: <692074f0-184f-e506-40a1-8fc078d1e706@intel.com>
On 11/29/2016 11:27 PM, Dave Hansen wrote:
> On 11/22/2016 06:19 AM, Anshuman Khandual wrote:
>> @@ -393,6 +393,9 @@ enum node_states {
>> N_MEMORY = N_HIGH_MEMORY,
>> #endif
>> N_CPU, /* The node has one or more cpus */
>> +#ifdef CONFIG_COHERENT_DEVICE
>> + N_COHERENT_DEVICE,
>> +#endif
>> NR_NODE_STATES
>> };
>
> Don't we really want this to be N_MEMORY_ISOLATED? Or, better yet,
Sure, If we move from a CDM description to a purely node isolation one.
I am still thinking through this.
> N_MEMORY_UNISOLATED so that we can just drop the bitmap in for N_MEMORY
Did not get that, N_MEMORY_UNISOLATED for the system RAM nodes which are
not isolated ? Then where the isolated/CDM nodes go in ?
> and not have to do any bit manipulation operations at runtime.
>
next prev parent reply other threads:[~2016-11-30 11:46 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-22 14:19 [RFC 0/4] Define coherent device memory node Anshuman Khandual
2016-11-22 14:19 ` Anshuman Khandual
2016-11-22 14:19 ` [RFC 1/4] mm: " Anshuman Khandual
2016-11-22 14:19 ` Anshuman Khandual
2016-11-29 17:57 ` Dave Hansen
2016-11-29 17:57 ` Dave Hansen
2016-11-30 11:46 ` Anshuman Khandual [this message]
2016-11-30 11:46 ` Anshuman Khandual
2016-11-22 14:19 ` [RFC 2/4] mm/cpuset: Exclude coherent device memory nodes from mems_allowed Anshuman Khandual
2016-11-22 14:19 ` Anshuman Khandual
2016-11-22 14:19 ` [RFC 3/4] mm/hugetlb: Restrict HugeTLB page allocations only to system ram nodemask Anshuman Khandual
2016-11-22 14:19 ` Anshuman Khandual
2016-11-22 14:19 ` [RFC 4/4] mm: Ignore cpuset enforcement when allocation flag has __GFP_THISNODE Anshuman Khandual
2016-11-22 14:19 ` Anshuman Khandual
2016-11-28 21:12 ` Dave Hansen
2016-11-28 21:12 ` Dave Hansen
2016-11-29 6:51 ` Anshuman Khandual
2016-11-29 6:51 ` Anshuman Khandual
2016-11-29 16:52 ` Dave Hansen
2016-11-29 16:52 ` Dave Hansen
2016-11-30 11:17 ` Anshuman Khandual
2016-11-30 11:17 ` Anshuman Khandual
2016-11-30 19:43 ` Dave Hansen
2016-11-30 19:43 ` Dave Hansen
2016-11-22 14:19 ` [DEBUG 05/12] powerpc/mm: Identify coherent device memory nodes during platform init Anshuman Khandual
2016-11-22 14:19 ` Anshuman Khandual
2016-11-22 14:19 ` [DEBUG 06/12] powerpc/mm: Create numa nodes for hotplug memory Anshuman Khandual
2016-11-22 14:19 ` Anshuman Khandual
2016-11-22 14:19 ` [DEBUG 07/12] powerpc/mm: Allow memory hotplug into a memory less node Anshuman Khandual
2016-11-22 14:19 ` Anshuman Khandual
2016-11-22 14:19 ` [DEBUG 08/12] mm: Enable CONFIG_MOVABLE_NODE on powerpc Anshuman Khandual
2016-11-22 14:19 ` Anshuman Khandual
2016-11-22 14:19 ` [DEBUG 09/12] powerpc: Enable CONFIG_MOVABLE_NODE for PPC64 platform Anshuman Khandual
2016-11-22 14:19 ` Anshuman Khandual
2016-11-22 14:19 ` [DEBUG 10/12] mm: Add a new migration function migrate_virtual_range() Anshuman Khandual
2016-11-22 14:19 ` Anshuman Khandual
2016-11-22 14:19 ` [DEBUG 11/12] drivers: Add two drivers for coherent device memory tests Anshuman Khandual
2016-11-22 14:19 ` Anshuman Khandual
2016-11-22 14:19 ` [DEBUG 12/12] test: Add a script to perform random VMA migrations across nodes Anshuman Khandual
2016-11-22 14:19 ` Anshuman Khandual
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=583EBBFC.7090700@linux.vnet.ibm.com \
--to=khandual@linux.vnet.ibm.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=bsingharora@gmail.com \
--cc=dave.hansen@intel.com \
--cc=haren@linux.vnet.ibm.com \
--cc=jglisse@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
--cc=srikar@linux.vnet.ibm.com \
--cc=vbabka@suse.cz \
/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.