On Mon, Nov 21, 2016 at 12:27:15PM +0530, Anshuman Khandual wrote: > On 11/21/2016 10:23 AM, Jerome Glisse wrote: > > On Mon, Nov 21, 2016 at 11:44:36AM +1100, Balbir Singh wrote: > >> > >> > >> On 19/11/16 05:18, Jérôme Glisse wrote: > >>> Only usefull for arch where we support ZONE_DEVICE and where we want to > >>> also support un-addressable device memory. We need struct page for such > >>> un-addressable memory. But we should avoid populating the kernel linear > >>> mapping for the physical address range because there is no real memory > >>> or anything behind those physical address. > >>> > >>> Hence we need more flags than just knowing if it is device memory or not. > >>> > >> > >> > >> Isn't it better to add a wrapper to arch_add/remove_memory and do those > >> checks inside and then call arch_add/remove_memory to reduce the churn. > >> If you need selectively enable MEMORY_UNADDRESSABLE that can be done with > >> _ARCH_HAS_FEATURE > > > > The flag parameter can be use by other new features and thus i thought the > > churn was fine. But i do not mind either way, whatever people like best. > > Right, once we get the device memory classification right, these flags > can be used in more places. > > > > > [...] > > > >>> -extern int arch_add_memory(int nid, u64 start, u64 size, bool for_device); > >>> + > >>> +/* > >>> + * For device memory we want more informations than just knowing it is device > >> information > >>> + * memory. We want to know if we can migrate it (ie it is not storage memory > >>> + * use by DAX). Is it addressable by the CPU ? Some device memory like GPU > >>> + * memory can not be access by CPU but we still want struct page so that we > >> accessed > >>> + * can use it like regular memory. > >> > >> Can you please add some details on why -- migration needs them for example? > > > > I am not sure what you mean ? DAX ie persistent memory device is intended to be > > use for filesystem or persistent storage. Hence memory migration does not apply > > to it (it would go against its purpose). > > Why ? It can still be used for compaction, HW errors etc where we need to > move between persistent storage areas. The source and destination can be > persistent storage memory. Well i don't think they intend to do migration for that, HW errors are hidden by hardware itself so far. But yes if they care then they could use page migration. So far it does not seems something any of the folks working on persistent memory think useful. Cheers, Jérôme -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>