On Fri, Apr 07, 2017 at 04:30:11PM +0100, Chris Wilson wrote:
> Not getting hangs is a good sign, but lockdep doesn't like it:
>
> [ 460.684901] WARNING: CPU: 1 PID: 172 at kernel/workqueue.c:2418
> check_flush_dependency+0x92/0x130
> [ 460.684924] workqueue: PF_MEMALLOC task 172(kworker/1:1H)
On Fri, Apr 07, 2017 at 03:32:30PM +0200, Andrea Arcangeli wrote:
> Hello Joonas,
> I kind I prefer my patch, just cleaned up with the
> synchronize_rcu_expedited under if (unlock) { mutex_unlock;
> synchronize_rcu... }.
Here a cleaned up version below using "unlock" instead
Hello Joonas,
On Fri, Apr 07, 2017 at 01:49:34PM +0300, Joonas Lahtinen wrote:
> diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> index 2978acd..129ed30 100644
> --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/i915_ge
On Fri, Apr 07, 2017 at 10:58:38AM +0100, Chris Wilson wrote:
> On Fri, Apr 07, 2017 at 01:23:47AM +0200, Andrea Arcangeli wrote:
> > Insist to run llist_del_all() until the free_list is found empty, this
> > may avoid having to schedule more workqueues.
>
> The work will
On Fri, Apr 07, 2017 at 11:02:11AM +0100, Chris Wilson wrote:
> On Fri, Apr 07, 2017 at 01:23:44AM +0200, Andrea Arcangeli wrote:
> > Waiting a RCU grace period only guarantees the work gets queued, but
> > until after the queued workqueue returns, there's no guarantee the
>
be i915 when the system is low on memory.
Andrea Arcangeli (5):
i915: avoid kernel hang caused by synchronize rcu struct_mutex
deadlock
i915: flush gem obj freeing workqueues to add accuracy to the i915
shrinker
i915: initialize the free_list of the fencing atomic_helper
i915: schedul
+0x40/0x40
? ret_from_fork+0x23/0x30
Signed-off-by: Andrea Arcangeli
---
drivers/gpu/drm/i915/i915_gem.c | 9 +
drivers/gpu/drm/i915/i915_gem_shrinker.c | 14 ++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/driver
ff-by: Andrea Arcangeli
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/i915_gem_shrinker.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3982489..612fde3 100644
--- a/drivers/gpu/drm/i915/i915_
Add cond_resched().
Signed-off-by: Andrea Arcangeli
---
drivers/gpu/drm/i915/i915_gem.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 612fde3..c81baeb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu
Insist to run llist_del_all() until the free_list is found empty, this
may avoid having to schedule more workqueues.
Signed-off-by: Andrea Arcangeli
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915
Just in case the llist model changes and NULL isn't valid
initialization.
Signed-off-by: Andrea Arcangeli
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ed
On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote:
> If it's an Iybridge, there's no low vswing, and that explanation is
> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
> on an unpatched kernel.
CC'ed Martin who filed the bz, he can reproduce too
https://bugzilla
On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote:
> If it's an Iybridge, there's no low vswing, and that explanation is
> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
> on an unpatched kernel.
What I should look for when trying those two settings? Will they
suc
13 matches
Mail list logo
