From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Matthew Auld <matthew.auld@intel.com>
Cc: igt-dev@lists.freedesktop.org, intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/i915/gem_exec_params: check available memory earlier
Date: Tue, 01 Mar 2022 14:24:38 -0800 [thread overview]
Message-ID: <87tuchfh09.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <20220301110359.663637-1-matthew.auld@intel.com>
On Tue, 01 Mar 2022 03:03:59 -0800, Matthew Auld wrote:
>
> The shmem mmap and pwrite interfaces conveniently let us probe just a
> few pages, without needing to populate the entire object. On discrete
> and newer platforms the kernel has dropped support for both, leaving us
> with MMAP_OFFSET, which will always populate the entire object, for now
> at least. Luckily we can just move the batch creation to after checking
> the available memory to ensure we don't hit -ENOMEM on such platforms.
>
> Also it seems that doing a massive allocation(filling much of system
> memory) and then calling intel_purge_vm_caches() seems to take 40+
> seconds, like when calling intel_require_memory(). Hence switching the
> ordering here should also help with that.
>
> For reference the larger-than-life test is just a simple regression test
> to ensure that some very large batch buffer(greater than ~4G) can't
> overflow the batch_len, causing all kinds of issues. See 57b2d834bf23
> ("drm/i915/gem: Support parsing of oversize batches").
I believe we tried this identical patch some time but don't remember why it
was never merged. Maybe it was not helping or more likely we weren't sure
it wouldn't break the test somehow (considering all the shmfs/swap
stuff). But if we think it's ok to merge this and may actually resolve the
-ENOMEM issue, this is:
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
prev parent reply other threads:[~2022-03-01 22:24 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-01 11:03 [Intel-gfx] [PATCH i-g-t] tests/i915/gem_exec_params: check available memory earlier Matthew Auld
2022-03-01 22:24 ` Dixit, Ashutosh [this message]
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=87tuchfh09.wl-ashutosh.dixit@intel.com \
--to=ashutosh.dixit@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
/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