mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2026-01-04 22:10:11 +01:00
read-only mirror of https://gitlab.freedesktop.org/mesa/mesa
6d6b22b734
When the system is under memory pressure (which can happen, for example, during CI runs), don't immediately give up the exec ioctl (which, for Vulkan, will result in the device being declared lost). Instead, retry a little bit just like we do for i915.ko. This is a trade-off. One of the reasons to *not* have unified behavior regarding ENOMEM between i915.ko and xe.ko is the fact that xe.ko uses vm_bind, so if the user tried to bind more memory than it is able to, we'll just keep getting ENOMEM as long as we retry the ioctl. We now have a retry limit, so we'll eventually return the error. On the other hand, if the problem is other applications consuming all the memory, having the retry loop may really help avoid unnecessarily marking the device as lost, since one of our retries may eventually succeed. I believe the tradeoff of "we'll now eventually succeed in some cases where it's possible to succeed, at the expense of retrying for a few seconds until giving up in cases where we would never be able to succeed" is an improvement. If xe.ko ever gives us a way to differentiate between the two different reasons for ENOMEM, we'll be able to make things much better. We can also tune our timeouts if needed. Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37559> |
||
|---|---|---|
| .ci-farms | ||
| .ci-farms-disabled | ||
| .github/workflows | ||
| .gitlab | ||
| .gitlab-ci | ||
| .marge/hooks | ||
| android | ||
| bin | ||
| build-support | ||
| docs | ||
| include | ||
| licenses | ||
| src | ||
| subprojects | ||
| .clang-format | ||
| .clang-format-ignore | ||
| .clang-format-include | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .graphqlrc.yml | ||
| .mailmap | ||
| .mr-label-maker.yml | ||
| .shellcheckrc | ||
| CODEOWNERS | ||
| meson.build | ||
| meson.options | ||
| README.rst | ||
| rustfmt.toml | ||
| VERSION | ||
`Mesa <https://mesa3d.org>`_ - The 3D Graphics Library ====================================================== Source ------ This repository lives at https://gitlab.freedesktop.org/mesa/mesa. Other repositories are likely forks, and code found there is not supported. Build & install --------------- You can find more information in our documentation (`docs/install.rst <https://docs.mesa3d.org/install.html>`_), but the recommended way is to use Meson (`docs/meson.rst <https://docs.mesa3d.org/meson.html>`_): .. code-block:: sh $ meson setup build $ ninja -C build/ $ sudo ninja -C build/ install Support ------- Many Mesa devs hang on IRC; if you're not sure which channel is appropriate, you should ask your question on `OFTC's #dri-devel <irc://irc.oftc.net/dri-devel>`_, someone will redirect you if necessary. Remember that not everyone is in the same timezone as you, so it might take a while before someone qualified sees your question. To figure out who you're talking to, or which nick to ping for your question, check out `Who's Who on IRC <https://dri.freedesktop.org/wiki/WhosWho/>`_. The next best option is to ask your question in an email to the mailing lists: `mesa-dev\@lists.freedesktop.org <https://lists.freedesktop.org/mailman/listinfo/mesa-dev>`_ Bug reports ----------- If you think something isn't working properly, please file a bug report (`docs/bugs.rst <https://docs.mesa3d.org/bugs.html>`_). Contributing ------------ Contributions are welcome, and step-by-step instructions can be found in our documentation (`docs/submittingpatches.rst <https://docs.mesa3d.org/submittingpatches.html>`_). Note that Mesa uses gitlab for patches submission, review and discussions.