Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1360090
| From | Olu Ogunbowale <olu.ogunbowale@imgtec.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] mm: Export symbols unmapped_area() & unmapped_area_topdown() |
| Date | 2016-03-17 18:50 +0100 |
| Message-ID | <rdKdB-1Zz-23@gated-at.bofh.it> (permalink) |
| References | <rdnh0-3tX-13@gated-at.bofh.it> <rdnh0-3tX-11@gated-at.bofh.it> <rdHfI-9X-17@gated-at.bofh.it> <rdIls-MU-17@gated-at.bofh.it> <rdJAT-1Mf-23@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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.
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH] mm: Export symbols unmapped_area() & unmapped_area_topdown() Olu Ogunbowale <Olu.Ogunbowale@imgtec.com> - 2016-03-16 18:20 +0100
Re: [PATCH] mm: Export symbols unmapped_area() & unmapped_area_topdown() Christoph Hellwig <hch@infradead.org> - 2016-03-16 21:40 +0100
Re: [PATCH] mm: Export symbols unmapped_area() & unmapped_area_topdown() Rik van Riel <riel@redhat.com> - 2016-03-16 22:10 +0100
Re: [PATCH] mm: Export symbols unmapped_area() & unmapped_area_topdown() Ingo Molnar <mingo@kernel.org> - 2016-03-17 08:30 +0100
Re: [PATCH] mm: Export symbols unmapped_area() & unmapped_area_topdown() Olu Ogunbowale <olu.ogunbowale@imgtec.com> - 2016-03-17 17:50 +0100
Re: [PATCH] mm: Export symbols unmapped_area() & unmapped_area_topdown() Jerome Glisse <j.glisse@gmail.com> - 2016-03-17 15:40 +0100
Re: [PATCH] mm: Export symbols unmapped_area() & unmapped_area_topdown() Oded Gabbay <oded.gabbay@gmail.com> - 2016-03-17 16:40 +0100
Re: [PATCH] mm: Export symbols unmapped_area() & unmapped_area_topdown() Olu Ogunbowale <olu.ogunbowale@imgtec.com> - 2016-03-17 16:50 +0100
Re: [PATCH] mm: Export symbols unmapped_area() & unmapped_area_topdown() Jerome Glisse <j.glisse@gmail.com> - 2016-03-17 18:10 +0100
Re: [PATCH] mm: Export symbols unmapped_area() & unmapped_area_topdown() Olu Ogunbowale <olu.ogunbowale@imgtec.com> - 2016-03-17 18:50 +0100
csiph-web