From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [RFC PATCH] drm/i915: Suppress page allocation warnings on engine park
Date: Thu, 02 Apr 2020 13:12:55 +0200 [thread overview]
Message-ID: <5b6dffae85775e03430f6b5f145dce89de5f090b.camel@linux.intel.com> (raw)
In-Reply-To: <158582415436.5852.10336291395981297377@build.alporthouse.com>
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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-04-02 11:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-02 10:19 [Intel-gfx] [RFC PATCH] drm/i915: Suppress page allocation warnings on engine park Janusz Krzysztofik
2020-04-02 10:21 ` Chris Wilson
2020-04-02 10:28 ` Janusz Krzysztofik
2020-04-02 10:32 ` Chris Wilson
2020-04-02 10:36 ` Janusz Krzysztofik
2020-04-02 10:42 ` Chris Wilson
2020-04-02 11:12 ` Janusz Krzysztofik [this message]
2020-04-02 10:57 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5b6dffae85775e03430f6b5f145dce89de5f090b.camel@linux.intel.com \
--to=janusz.krzysztofik@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox