Re: [PATCH 1/3] drm/etnaviv: don't trigger OOM killer when page allocation fails

2017-06-26 Thread 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 
> > > > ---
> > > >  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-mho...@kernel.org
-- 
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/etnaviv: don't trigger OOM killer when page allocation fails

2017-06-26 Thread Lucas Stach 
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 
> > > > > ---
> > > > >  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-mho...@kernel.org

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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/etnaviv: don't trigger OOM killer when page allocation fails

2017-06-20 Thread Daniel Vetter 
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 
> > > ---
> > >  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 :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/etnaviv: don't trigger OOM killer when page allocation fails

2017-06-20 Thread Lucas Stach 
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 
> > ---
> >  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.

Regards,
Lucas

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/etnaviv: don't trigger OOM killer when page allocation fails

2017-06-20 Thread 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 
> ---
>  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.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/etnaviv: don't trigger OOM killer when page allocation fails

2017-06-06 Thread Lucas Stach 
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 
---
 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);
}
 
if (ret)
-- 
2.9.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel