linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jerome Glisse <j.glisse@gmail.com>
To: Olu Ogunbowale <Olu.Ogunbowale@imgtec.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Michel Lespinasse <walken@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>, Hugh Dickins <hughd@google.com>,
	Russell King <linux@arm.linux.org.uk>,
	Ralf Baechle <ralf@linux-mips.org>,
	Paul Mundt <lethal@linux-sh.org>,
	"David S. Miller" <davem@davemloft.net>,
	Chris Metcalf <cmetcalf@tilera.com>, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] mm: Export symbols unmapped_area() & unmapped_area_topdown()
Date: Thu, 17 Mar 2016 15:37:16 +0100	[thread overview]
Message-ID: <20160317143714.GA16297@gmail.com> (raw)
In-Reply-To: <1458148234-4456-2-git-send-email-Olu.Ogunbowale@imgtec.com>

On Wed, Mar 16, 2016 at 05:10:34PM +0000, Olu Ogunbowale wrote:
> From: Olujide Ogunbowale <Olu.Ogunbowale@imgtec.com>
> 
> Export the memory management functions, unmapped_area() &
> unmapped_area_topdown(), as GPL symbols; this allows the kernel to
> better support process address space mirroring on both CPU and device
> for out-of-tree drivers by allowing the use of vm_unmapped_area() in a
> driver's file operation get_unmapped_area().
> 
> This is required by drivers that want to control or limit a process VMA
> range into which shared-virtual-memory (SVM) buffers are mapped during
> an mmap() call in order to ensure that said SVM VMA does not collide
> with any pre-existing VMAs used by non-buffer regions on the device
> because SVM buffers must have identical VMAs on both CPU and device.
> 
> Exporting these functions is particularly useful for graphics devices as
> SVM support is required by the OpenCL & HSA specifications and also SVM
> support for 64-bit CPUs where the useable device SVM address range
> is/maybe a subset of the full 64-bit range of the CPU. Exporting also
> avoids the need to duplicate the VMA search code in such drivers.

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.

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.

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.

Cheers,
Jerome

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2016-03-17 14:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-16 17:10 Mirroring process address space on device Olu Ogunbowale
2016-03-16 17:10 ` [PATCH] mm: Export symbols unmapped_area() & unmapped_area_topdown() Olu Ogunbowale
2016-03-16 20:36   ` Christoph Hellwig
2016-03-16 21:00     ` Rik van Riel
2016-03-17  7:24       ` Ingo Molnar
2016-03-17 14:37   ` Jerome Glisse [this message]
2016-03-17 15:38     ` Oded Gabbay
2016-03-17 15:46     ` Olu Ogunbowale
2016-03-17 17:03       ` Jerome Glisse
2016-03-17 17:42         ` Olu Ogunbowale

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160317143714.GA16297@gmail.com \
    --to=j.glisse@gmail.com \
    --cc=Olu.Ogunbowale@imgtec.com \
    --cc=akpm@linux-foundation.org \
    --cc=cmetcalf@tilera.com \
    --cc=davem@davemloft.net \
    --cc=hpa@zytor.com \
    --cc=hughd@google.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mingo@elte.hu \
    --cc=ralf@linux-mips.org \
    --cc=riel@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=walken@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).