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


Groups > linux.kernel > #1359967

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 16:50 +0100
Message-ID <rdIls-MU-17@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>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, Mar 17, 2016 at 03:37:16PM +0100, Jerome Glisse wrote:
> What other driver do for non-buffer region is have the userspace side
> of the device driver mmap the device driver file and use vma range you
> get from that for those non-buffer region. On cpu access you can either
> chose to fault or to return a dummy page. With that trick no need to
> change kernel.

Yes, this approach works for some designs however arbitrary VMA ranges 
for non-buffer regions is not a feature of all mobile gpu designs for 
performance, power, and area (PPA) reasons.

> Note that i do not see how you can solve the issue of your GPU having
> less bits then the cpu. For instance, lets assume that you have 46bits
> for the GPU while the CPU have 48bits. Now an application start and do
> bunch of allocation that end up above (1 << 46), then same application
> load your driver and start using some API that allow to transparently
> use previously allocated memory -> fails.

Yes, you are correct however for mobile SoC(s) though current top-end 
specifications have 4GB/8GB of installed ram so the usable SVM range is 
upper bound by this giving a fixed base hence the need for driver control
of VMA range.

> Unless you are in scheme were all allocation must go through some
> special allocator but i thought this was not the case for HSA. I know
> lower level of OpenCL allows that.

Subsets of both specifications allows for restricted implementation AFAIK,
this proposed changes are for HSA and OpenCL up to phase 2, where all SVM
allocations go via special user mode allocator.

Regards,
Olu

Back to linux.kernel | Previous | NextPrevious in thread | Next 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