Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1360090

Re: [PATCH] mm: Export symbols unmapped_area() & unmapped_area_topdown()

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

Show all headers | View raw


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 | NextPrevious in thread | Find similar | Unroll thread


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