All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Inki Dae <inki.dae@samsung.com>
Cc: Jerome Glisse <jglisse@redhat.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Kyungmin Park <kyungmin.park@samsung.com>
Subject: Re: [PATCH] exynos: Put a stop to the userptr heresy.
Date: Thu, 10 Jul 2014 09:11:36 +0200	[thread overview]
Message-ID: <20140710071136.GE17271@phenom.ffwll.local> (raw)
In-Reply-To: <53BD622C.9050000@samsung.com>

On Thu, Jul 10, 2014 at 12:39:24AM +0900, Inki Dae wrote:
> On 2014년 07월 09일 18:23, Daniel Vetter wrote:
> > On Tue, Jul 8, 2014 at 6:20 PM, Inki Dae <inki.dae@samsung.com> wrote:
> >> 2014-07-08 22:37 GMT+09:00 Daniel Vetter <daniel@ffwll.ch>:
> >>> On Wed, Jul 02, 2014 at 11:25:19AM -0400, Jerome Glisse wrote:
> >>>> Anyway as this is upstream i guess you can keep it. This is just an horrible
> >>>> API that allow to circumvant any limit set by memcg for page locking and all.
> >>>> But anyway GPU driver never played in the same ballpark as other driver.
> >>>
> >>> I agree that exynos userptr as-is should be removed since as opposed to
> >>> the i915 implementation it doesn't play nice with the core mm
> >>
> >> Can you give me more details why you think so?
> > 
> >>From a very quick look there's two pieces:
> > - The implementation with the vma tricks looks _really_ scary. You'd
> > need to have Al Viro's opinion on it though.
> 
> You mean that it checks VM_DONTCOPY flag before copying vma? If so, I
> really forgot it.
> 
> > - If I'm reading the code correctly userspace can pin unlimted amounts
> > of memory, but I've gotten a bit lost in the code. In i915 we have
> 
> Not so. g2d driver is checking if user-requested buffer size is more
> than maximum capacity of g2d dma. So it can never pin unlimited amounts
> of memory.

Ah I didn't spot this check. I guess if the g2d dma size is a natural
limit then we're fine. Nowadays on recent i915 hw/sw we can use all of
system memory, so can't rely on some hw limit to limit the amount of
memory userspace can mlock. But if g2d has that (and there's enough memory
left for the kernel to not fall over) you should be fine.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

      reply	other threads:[~2014-07-10  7:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-30 21:46 [PATCH] exynos: Put a stop to the userptr heresy j.glisse
2014-07-01  8:55 ` Inki Dae
2014-07-01 15:03   ` Jerome Glisse
2014-07-02 15:09     ` Inki Dae
2014-07-02 15:25       ` Jerome Glisse
2014-07-08 13:37         ` Daniel Vetter
2014-07-08 16:20           ` Inki Dae
2014-07-09  9:23             ` Daniel Vetter
2014-07-09 15:39               ` Inki Dae
2014-07-10  7:11                 ` Daniel Vetter [this message]

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=20140710071136.GE17271@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=inki.dae@samsung.com \
    --cc=jglisse@redhat.com \
    --cc=kyungmin.park@samsung.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.