On Wed, Aug 24, 2016 at 9:56 AM, Christian König <deathsimple at vodafone.de> wrote: > Am 23.08.2016 um 21:55 schrieb Marek Olšák: >> >> On Tue, Aug 23, 2016 at 8:01 PM, Marek Olšák <maraeo at gmail.com> wrote: >>> >>> On Thu, Aug 18, 2016 at 10:52 AM, Christian König >>> <deathsimple at vodafone.de> wrote: >>>> >>>> In that case my patch should clearly help with that. >>>> >>>> Going to release what I have so far today, but looks like I need more >>>> time >>>> actually fixing this. >>>> >>>> In the meantime you could try the "drm/amdgpu: fix lru size grouping" >>>> patch >>>> as well. It fixes a bug related to this and could help as well. >>> >>> Thanks. "drm/amdgpu: fix lru size grouping" does help a lot and >>> removes most of the long stalls. >>> >>> There are still some spikes in the number of moved bytes, but rarely >>> do they cause long stalls and the number of moved bytes is lower now >>> (e.g. >>> the spikes are at 512MB/s instead of 4GB/s). >> >> Shouldn't "drm/amdgpu: fix lru size grouping" be a candidate for >> stable since it improves usability of the driver and seems to fix a >> regression? > > > Yeah, probably. But when did the TTM LRU handling got upstream? > > Alex, wasn't that just in the current cycle? I complete lost track when > stuff goes upstream because of the internal branch we use to work with now. "drm/amdgpu: group BOs by log2 of the size on the LRU v2" was first in v4.7, so it should be a candidate for 4.7. Marek
