On 10/01/2019 10:47, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-10 10:24:09)
On 09/01/2019 16:42, Chris Wilson wrote:
If the current process is being killed (it was interrupted with SIGKILL
or equivalent), it will not make any progress in page allocation and we
can abort performing the shrinking on its behalf. So we can use
mutex_lock_killable() instead (although this path should only be
reachable from kswapd currently).
kswapd is hopefully not killable so it is not reachable via that route.
But should be via other i915_gem_shrink_all callers. Is it starting to
look like we need to pass some flags to say
normal/interruptible/killable (kswapd/debugfs/?)?
killable is justifiable for all callers, I think, even if SIGKILL may
never be delivered. interruptible? Do we want to conceptually fail a
As long as using mutex_lock_killable doesn't make something killable
which otherwise wouldn't be. I have to say I don't know how the details
of that work.
kmalloc due to a signal, as that's likely to end up with ENOMEM and not
EINTR. (Pretty sure that's not common practice but there's a bit of
shrink-unless-killable around.) So I don't think we need to make
normal aka uninterruptible a special case, and returning before
shrinking on any signal seems unexpected.
debugfs was the only reason I considered interruptible. There I think
makes sense to allow bail up. I hate stuck shell sessions at least so
anything which can be done to avoid them is tempting.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
