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 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. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
