On Thu, 2020-04-02 at 11:42 +0100, Chris Wilson wrote: > Quoting Janusz Krzysztofik (2020-04-02 11:36:21) > > On Thu, 2020-04-02 at 11:32 +0100, Chris Wilson wrote: > > > Quoting Janusz Krzysztofik (2020-04-02 11:28:03) > > > > On Thu, 2020-04-02 at 11:21 +0100, Chris Wilson wrote: > > > > > Quoting Janusz Krzysztofik (2020-04-02 11:19:06) > > > > > > On memory constrained systems it may happen that no pages are available > > > > > > for serving object creation attempt during engine park. Since we can > > > > > > and we do ignore that failure, let's suppress possible warnings from > > > > > > page allocator to avoid confusion and make CI happy. > > > > > > > > > > The effect of ignoring it though is dangerous, hence why I had a > > > > > warning. > > > > > > > > Then maybe just WARN() from switch_to_kernel_context() on > > > > __i915_request_create() returning -ENOMEM instead? > > > > > > The warning exists already. The only real question is what to do about > > > it; the best answer would be to preallocate the final request during > > > unpark where we can report an error, but that would take a bit more > > > effort to refactor request allocation. Hence the warning to make it a > > > futureselves problem. > > > > I meant a warning with a very specific message that could be filtered > > easily by CI for now. > > It has a very specific stacktrace, If CI is able to filter on specific stacktrace then OK. > and I hope by filtered you mean > identified and reported as an issue, possibly with multiple causes since > this is an indication that reclaim is snafu. Identified and reported as the reclaim issue specifically rather than something quite general like: TGL: igt@gem_exec_create@madvise - dmesg-warn - SUCCESS, page allocation failure: order:0, mode:0x40810(GFP_NOWAIT|__GFP_COMP|__GFP_RECLAIMABLE), nodemask=(null) Thanks, Janusz > -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
