On 10/24/2016 01:04 PM, Dave Hansen wrote:

On 10/23/2016 09:31 PM, Anshuman Khandual wrote:

quoted

	To achieve seamless integration  between system RAM and coherent
device memory it must be able to utilize core memory kernel features like
anon mapping, file mapping, page cache, driver managed pages, HW poisoning,
migrations, reclaim, compaction, etc.

So, you need to support all these things, but not autonuma or hugetlbfs?
  What's the reasoning behind that?

If you *really* don't want a "cdm" page to be migrated, then why isn't
that policy set on the VMA in the first place?  That would keep "cdm"
pages from being made non-cdm.  And, why would autonuma ever make a
non-cdm page and migrate it in to cdm?  There will be no NUMA access
faults caused by the devices that are fed to autonuma.

Pages are desired to be migrateable, both into (starting cpu zone 
movable->cdm) and out of (starting cdm->cpu zone movable) but only 
through explicit migration, not via autonuma.  other pages in the same 
VMA should still be migrateable between CPU nodes via autonuma however.

Its expected a lot of these allocations are going to end up in THPs.  
I'm not sure we need to explicitly disallow hugetlbfs support but the 
identified use case is definitely via THPs not tlbfs.

--
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>