Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1538861
| From | Jerome Glisse <jglisse@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [HMM v14 05/16] mm/ZONE_DEVICE/unaddressable: add support for un-addressable device memory |
| Date | 2016-12-08 21:40 +0100 |
| Message-ID | <sMdDX-2iT-11@gated-at.bofh.it> (permalink) |
| References | <sM8XD-7OE-5@gated-at.bofh.it> <sM97k-7Se-19@gated-at.bofh.it> <sM9K3-8la-69@gated-at.bofh.it> <sMa3n-8rP-5@gated-at.bofh.it> <sMdaV-254-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
> On 12/08/2016 08:39 AM, Jerome Glisse wrote: > >> On 12/08/2016 08:39 AM, Jérôme Glisse wrote: > >>> > > Architecture that wish to support un-addressable device memory should > >>> > > make > >>> > > sure to never populate the kernel linar mapping for the physical > >>> > > range. > >> > > >> > Does the platform somehow provide a range of physical addresses for this > >> > unaddressable area? How do we know no memory will be hot-added in a > >> > range we're using for unaddressable device memory, for instance? > > That's what one of the big issue. No platform does not reserve any range so > > there is a possibility that some memory get hotpluged and assign this > > range. > > > > I pushed the range decision to higher level (ie it is the device driver > > that > > pick one) so right now for device driver using HMM (NVidia close driver as > > we don't have nouveau ready for that yet) it goes from the highest physical > > address and scan down until finding an empty range big enough. > > I don't think you should be stealing physical address space for things > that don't and can't have physical addresses. Delegating this to > individual device drivers and hoping that they all get it right seems > like a recipe for disaster. Well i expected device driver to use hmm_devmem_add() which does not take physical address but use the above logic to pick one. > > Maybe worth adding to the changelog: > > This feature potentially breaks memory hotplug unless every > driver using it magically predicts the future addresses of > where memory will be hotplugged. I will add debug printk to memory hotplug in case it fails because of some un-addressable resource. If you really dislike memory hotplug being broken then i can go down the way of allowing to hotplug memory above the max physical memory limit. This require more changes but i believe this is doable for some of the memory model (sparsemem and sparsemem extreme). > > BTW, how many more of these "big issues" does this set have? I didn't > see any mention of this in the changelogs. I am not sure what to say here. If you don't use HMM ie no device that hotplug it. Then there is no chance of having issue. If you have a device that use it then someone might try to do something stupid (try to kmap and access such un-addressable page for instance). So i am not sure where to draw the line. Cheers, Jérôme
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[HMM v14 00/16] HMM (Heterogeneous Memory Management) v14 Jérôme Glisse <jglisse@redhat.com> - 2016-12-08 16:40 +0100
[HMM v14 12/16] mm/hmm/migrate: add new boolean copy flag to migratepage() callback Jérôme Glisse <jglisse@redhat.com> - 2016-12-08 16:40 +0100
[HMM v14 01/16] mm/free_hot_cold_page: catch ZONE_DEVICE pages Jérôme Glisse <jglisse@redhat.com> - 2016-12-08 16:50 +0100
[HMM v14 06/16] mm/ZONE_DEVICE/x86: add support for un-addressable device memory Jérôme Glisse <jglisse@redhat.com> - 2016-12-08 16:50 +0100
[HMM v14 03/16] mm/ZONE_DEVICE/devmem_pages_remove: allow early removal of device memory Jérôme Glisse <jglisse@redhat.com> - 2016-12-08 16:50 +0100
[HMM v14 13/16] mm/hmm/migrate: new memory migration helper for use with device memory v2 Jérôme Glisse <jglisse@redhat.com> - 2016-12-08 16:50 +0100
[HMM v14 07/16] mm/hmm: heterogeneous memory management (HMM for short) Jérôme Glisse <jglisse@redhat.com> - 2016-12-08 16:50 +0100
[HMM v14 05/16] mm/ZONE_DEVICE/unaddressable: add support for un-addressable device memory Jérôme Glisse <jglisse@redhat.com> - 2016-12-08 16:50 +0100
Re: [HMM v14 05/16] mm/ZONE_DEVICE/unaddressable: add support for un-addressable device memory Dave Hansen <dave.hansen@intel.com> - 2016-12-08 17:30 +0100
Re: [HMM v14 05/16] mm/ZONE_DEVICE/unaddressable: add support for un-addressable device memory Jerome Glisse <jglisse@redhat.com> - 2016-12-08 17:50 +0100
Re: [HMM v14 05/16] mm/ZONE_DEVICE/unaddressable: add support for un-addressable device memory Dave Hansen <dave.hansen@intel.com> - 2016-12-08 21:10 +0100
Re: [HMM v14 05/16] mm/ZONE_DEVICE/unaddressable: add support for un-addressable device memory Jerome Glisse <jglisse@redhat.com> - 2016-12-08 21:40 +0100
[HMM v14 02/16] mm/memory/hotplug: convert device bool to int to allow for more flags v2 Jérôme Glisse <jglisse@redhat.com> - 2016-12-08 16:50 +0100
[HMM v14 16/16] mm/hmm/devmem: dummy HMM device as an helper for ZONE_DEVICE memory Jérôme Glisse <jglisse@redhat.com> - 2016-12-08 16:50 +0100
[HMM v14 04/16] mm/ZONE_DEVICE/free-page: callback when page is freed Jérôme Glisse <jglisse@redhat.com> - 2016-12-08 16:50 +0100
[HMM v14 15/16] mm/hmm/devmem: device driver helper to hotplug ZONE_DEVICE memory Jérôme Glisse <jglisse@redhat.com> - 2016-12-08 16:50 +0100
[HMM v14 10/16] mm/hmm/mirror: device page fault handler Jérôme Glisse <jglisse@redhat.com> - 2016-12-08 16:50 +0100
[HMM v14 08/16] mm/hmm/mirror: mirror process address space on device with HMM helpers Jérôme Glisse <jglisse@redhat.com> - 2016-12-08 16:50 +0100
[HMM v14 14/16] mm/hmm/migrate: optimize page map once in vma being migrated Jérôme Glisse <jglisse@redhat.com> - 2016-12-08 16:50 +0100
[HMM v14 09/16] mm/hmm/mirror: helper to snapshot CPU page table Jérôme Glisse <jglisse@redhat.com> - 2016-12-08 16:50 +0100
csiph-web