Summary: | `ttm_bo_handle_move_mem` sometimes takes more than 50 ms | ||||||
---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Paul Menzel <pmenzel+bugs.freedesktop.org> | ||||
Component: | DRM/AMDgpu | Assignee: | Default DRI bug account <dri-devel> | ||||
Status: | RESOLVED MOVED | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | medium | ||||||
Version: | XOrg git | ||||||
Hardware: | Other | ||||||
OS: | All | ||||||
Whiteboard: | |||||||
i915 platform: | i915 features: | ||||||
Attachments: |
|
Description
Paul Menzel
2019-08-06 10:15:16 UTC
The contents of vram have to be moved to system memory on suspend since vram is powered off. Depending on general memory pressure at suspend time it may take a while to get the contexts of vram into system ram. (In reply to Alex Deucher from comment #1) > The contents of vram have to be moved to system memory on suspend since vram > is powered off. Depending on general memory pressure at suspend time it may > take a while to get the contexts of vram into system ram. Just to clarify, the VRAM on the external graphics device is powered off, correct? Are there any tools to analyze these delays? (In reply to Paul Menzel from comment #2) > > Just to clarify, the VRAM on the external graphics device is powered off, > correct? Correct. > > Are there any tools to analyze these delays? I guess profiling the relevant functions in ttm. See if we are waiting on pages, etc. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/886. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.