On Thu, 25 Sep 2014 14:55:02 -0400 Peter Hurley peter@hurleysoftware.com wrote:
After several days uptime with a 3.16 kernel (generally running Thunderbird, emacs, kernel builds, several Chrome tabs on multiple desktop workspaces) I've been seeing some really extreme slowdowns.
Mostly the slowdowns are associated with gpu-related tasks, like opening new emacs windows, switching workspaces, laughing at internet gifs, etc. Because this x86_64 desktop is nouveau-based, I didn't pursue it right away -- 3.15 is the first time suspend has worked reliably.
This week I started looking into what the slowdown was and discovered it's happening during dma allocation through swiotlb (the cpus can do intel iommu but I don't use it because it's not the default for most users).
I'm still working on a bisection but each step takes 8+ hours to validate and even then I'm no longer sure I still have the 'bad' commit in the bisection. [edit: yup, I started over]
There are six ttm patches queued for 3.16.4:
drm-ttm-choose-a-pool-to-shrink-correctly-in-ttm_dma_pool_shrink_scan.patch drm-ttm-fix-handling-of-ttm_pl_flag_topdown-v2.patch drm-ttm-fix-possible-division-by-0-in-ttm_dma_pool_shrink_scan.patch drm-ttm-fix-possible-stack-overflow-by-recursive-shrinker-calls.patch drm-ttm-pass-gfp-flags-in-order-to-avoid-deadlock.patch drm-ttm-use-mutex_trylock-to-avoid-deadlock-inside-shrinker-functions.patch