Messages in this thread | | | Subject | Re: [PATCH V3 0/4] Define coherent device memory node | From | Balbir Singh <> | Date | Wed, 1 Mar 2017 13:42:40 +1100 |
| |
>>> The idea of this patchset was to introduce >>> the concept of memory that is not necessarily system memory, but is coherent >>> in terms of visibility/access with some restrictions >>> >> >> Which should be done without special casing the page allocator, cpusets and >> special casing how cpusets are handled. It's not necessary for any other >> mechanism used to restrict access to portions of memory such as cpusets, >> mempolicies or even memblock reservations. > > Agreed, I mentioned a limitation that we see a cpusets. I do agree that > we should reuse any infrastructure we have, but cpusets are more static > in nature and inheritence compared to the requirements of CDM. >
Mel, I went back and looked at cpusets and found some limitations that I mentioned earlier, isolating a particular node requires some amount of laborious work in terms of isolating all tasks away from the root cpuset and then creating a hierarchy where the root cpuset is empty and now belong to a child cpuset that has everything but the node we intend to ioslate. Even with hardwalling, it does not prevent allocations from the parent cpuset.
I am trying to understand the concerns that you/Michal/Vlastimil have so that Anshuman/I/other stake holders can respond to the concerns in one place if that makes sense. Here are the concerns I have heard so far
1. Lets not add any overhead to the page allocator path 2. Lets try and keep the allocator changes easy to read/parse 3. Why do we need a NUMA interface? 4. How does this compare with HMM? 5. Why can't we use cpusets?
Would that be a fair set of concerns to address?
@Anshuman/@Srikar/@Aneesh anything else you'd like to add in terms of concerns/issues? I think it will also make a good discussion thread for those attending LSF/MM (I am not there) on this topic.
Balbir Singh.
| |