| Message ID | 20190315162538.4120-3-paul.kocialkowski@bootlin.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/3] drm/file: Rehabilitate the firstopen hook for non-legacy drivers | expand |
Paul Kocialkowski <paul.kocialkowski@bootlin.com> writes: > The binner BO is a pre-requisite to GPU operations, so we must ensure > that it is always allocated when the GPU is in use. > > Because the buffer is allocated from the same pool as other GPU buffers, > we might run into a situation where we are out of memory at runtime > resume. This causes the binner BO allocation to fail and results in all > subsequent operations to fail, resulting in a major hang in userspace. > > Now that we allocate the buffer at firstopen and liberate it at > lastclose, we can just keep it alive during runtime suspend. I think this needs to be squashed into the previous patch, as otherwise coming from suspended, a firstopen -> resume -> render will leak a copy of the bin BO.
Hi, Le samedi 16 mars 2019 à 11:58 -0700, Eric Anholt a écrit : > Paul Kocialkowski <paul.kocialkowski@bootlin.com> writes: > > > The binner BO is a pre-requisite to GPU operations, so we must ensure > > that it is always allocated when the GPU is in use. > > > > Because the buffer is allocated from the same pool as other GPU buffers, > > we might run into a situation where we are out of memory at runtime > > resume. This causes the binner BO allocation to fail and results in all > > subsequent operations to fail, resulting in a major hang in userspace. > > > > Now that we allocate the buffer at firstopen and liberate it at > > lastclose, we can just keep it alive during runtime suspend. > > I think this needs to be squashed into the previous patch, as otherwise > coming from suspended, a firstopen -> resume -> render will leak a copy > of the bin BO. Woops, you're definitely right: vc4_allocate_bin_bo won't check whether we already have allocated it or not. I'll send a new version with both patches squashed. Cheers, Paul
diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c index ab15e71df001..e04a51a75f01 100644 --- a/drivers/gpu/drm/vc4/vc4_v3d.c +++ b/drivers/gpu/drm/vc4/vc4_v3d.c @@ -303,9 +303,6 @@ static int vc4_v3d_runtime_suspend(struct device *dev) vc4_irq_uninstall(vc4->dev); - drm_gem_object_put_unlocked(&vc4->bin_bo->base.base); - vc4->bin_bo = NULL; - clk_disable_unprepare(v3d->clk); return 0; @@ -317,10 +314,6 @@ static int vc4_v3d_runtime_resume(struct device *dev) struct vc4_dev *vc4 = v3d->vc4; int ret; - ret = vc4_allocate_bin_bo(vc4->dev); - if (ret) - return ret; - ret = clk_prepare_enable(v3d->clk); if (ret != 0) return ret;
The binner BO is a pre-requisite to GPU operations, so we must ensure that it is always allocated when the GPU is in use. Because the buffer is allocated from the same pool as other GPU buffers, we might run into a situation where we are out of memory at runtime resume. This causes the binner BO allocation to fail and results in all subsequent operations to fail, resulting in a major hang in userspace. Now that we allocate the buffer at firstopen and liberate it at lastclose, we can just keep it alive during runtime suspend. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> --- drivers/gpu/drm/vc4/vc4_v3d.c | 7 ------- 1 file changed, 7 deletions(-)