Am Montag, den 26.06.2017, 07:52 +0200 schrieb Michal Hocko: > On Tue 20-06-17 11:25:24, Daniel Vetter wrote: > > On Tue, Jun 20, 2017 at 11:22:06AM +0200, Lucas Stach wrote: > > > Am Dienstag, den 20.06.2017, 11:06 +0200 schrieb Daniel Vetter: > > > > On Tue, Jun 06, 2017 at 09:17:06AM +0200, Lucas Stach wrote: > > > > > GPU buffers can be quite large, so userspace is expected to > > > > > deal with > > > > > allocation failure. Don't trigger the OOM killer when page > > > > > allocation for > > > > > the GEM objects fails, as this opens an easy possiblity for > > > > > unprivileged > > > > > applications to DOS the system,a s the shmem pages are not > > > > > fully accounted > > > > > to the allocating process. > > > > > > > > > > Signed-off-by: Lucas Stach <dev@xxxxxxxxxx> > > > > > --- > > > > > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 3 ++- > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c > > > > > b/drivers/gpu/drm/etnaviv/etnaviv_gem.c > > > > > index f0efc5d..4c53508 100644 > > > > > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c > > > > > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c > > > > > @@ -662,7 +662,8 @@ static struct drm_gem_object > > > > > *__etnaviv_gem_new(struct drm_device *dev, > > > > > * going to pin these pages. > > > > > */ > > > > > mapping = obj->filp->f_mapping; > > > > > - mapping_set_gfp_mask(mapping, GFP_HIGHUSER); > > > > > + mapping_set_gfp_mask(mapping, GFP_HIGHUSER | > > > > > + __GFP_NORETRY | > > > > > __GFP_NOWARN); > > > > > > > > _NORETRY means the mm does try hard at all to free memory. > > > > We've just done > > > > this patch in 4.12 and totally regret it, because now gpu tasks > > > > run out of > > > > memory with plenty of (gpu) memory available that could be > > > > reaped. > > > > > > > > There's some discussions going on with Michal Hocko and Chris > > > > Wilson > > > > about possible solutions for this without so much hacks. > > > > > > Thanks for the heads up. In contrast to some of the other drivers > > > Etnaviv hasn't grown a proper shrinker yet, so I still think this > > > patch > > > is a step in the right direction for the time being. > > > Currently with Etnaviv sitting on lots of GPU memory and the MM > > > trying > > > hard to free more memory for GPU usage a simple piglit run might > > > pressure the OOM killer hard enough to bring the system down by > > > killing > > > PID 1. > > > > Ah ok, that changes the balance of course. Time to type that > > shrinker I'd > > say :-) > > Yeah, shrinker sounds like an absolute must. Anyway, I've posted > __GFP_RETRY_MAYFAIL patchset [1] so you can use that flag. > > [1] http://lkml.kernel.org/r/20170623085345.11304-1-mhocko@xxxxxxxxxx Thanks, I'll switch etnaviv over to use this flag when the patchset gets applied. A proper shrinker is on the TODO list, but there are only so much hours in a day... Regards, Lucas _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
