From: "Christian König" <christian.koenig@amd.com>
To: Dave Airlie <airlied@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] drm/ttm/nouveau: don't call tt destroy callback on alloc failure.
Date: Wed, 29 Jul 2020 14:17:13 +0200 [thread overview]
Message-ID: <7ff77e1b-fee5-c4b3-a3f8-102d6d602a4f@amd.com> (raw)
In-Reply-To: <CAPM=9tzz2a3pAY3MkvVS+FCiOxX6WNs2bmooHO0E47i6P4V0JA@mail.gmail.com>
Am 29.07.20 um 02:08 schrieb Dave Airlie:
> [SNIP]
> Landed this in drm-next as well.
By the way there is another design bug in TTM which only affects
Nouveau. See ttm_mem_io_reserve_vm() and ttm_mem_io_free_vm().
What happens is that as soon as you have an userspace VM mapping the BO
ends up on the LRU and a flag noting that so that we don't free the VM
reference twice.
Additional to that we have a reference count to avoid calling the
io_mem_reserve and io_mem_free callbacks unbalanced if there are both
userspace VM mappings and kernel mappings for CPU copies of BOs or
kmap() etc...
But this design is complete nonsense.
What we need instead is some handling which prevents adding the io_mem
to the LRU as soon as there are any kernel mappings, because we can't
restore those using a fault.
I already tried to move the whole handling into Nouveau itself, so that
we can properly fix this up there. But Ben reported that my only compile
tested patches don't work and without hardware I can't finish them up.
Regards,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
prev parent reply other threads:[~2020-07-29 12:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-28 4:17 [PATCH] drm/ttm/nouveau: don't call tt destroy callback on alloc failure Dave Airlie
2020-07-28 7:48 ` Christian König
2020-07-29 0:08 ` Dave Airlie
2020-07-29 12:17 ` Christian König [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=7ff77e1b-fee5-c4b3-a3f8-102d6d602a4f@amd.com \
--to=christian.koenig@amd.com \
--cc=airlied@gmail.com \
--cc=bskeggs@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
/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