Messages in this thread | | | Date | Thu, 17 Mar 2016 17:42:26 +0000 | From | Olu Ogunbowale <> | Subject | Re: [PATCH] mm: Export symbols unmapped_area() & unmapped_area_topdown() |
| |
On Thu, Mar 17, 2016 at 06:03:50PM +0100, Jerome Glisse wrote: > Well trick still works, if driver is loaded early during userspace program > initialization then you force mmap to specific range inside the driver > userspace code. If driver is loaded after and program is already using those > range then you can register a notifier to track when those range. If they > get release by the program you can have the userspace driver force creation > of new reserve vma again.
I should have been more clearer in my response, this applies only because we are in a scheme were all allocations must go through a special allocator because VMA base/range is reserved for SVM.
> Well controling range into which VMA can be allocated is not something that > you should do lightly (thing like address space randomization would be > impacted). And no the SVM range is not upper bound by the amount of memory > but by the physical bus size if it is 48bits nothing forbid to put all the > program memory above 8GB and nothing below. We are talking virtual address > here. By the way i think most 64 bit ARM are 40 bits and it seems a shame > for GPU to not go as high as the CPU.
Same as above. By the way, we support minimum 40-bits but can be paired with CPU(s) of higher bits; no problem if bits are equal or greater than CPU.
| |