On 25/05/17 08:24 PM, Marek Olšák wrote: > On Thu, May 25, 2017 at 5:31 AM, Michel Dänzer <michel at daenzer.net> wrote: >> On 24/05/17 08:27 PM, Christian König wrote: >>> Am 24.05.2017 um 13:03 schrieb Marek Olšák: >>>>> >>>> I think the final solution (done in fault_reserve_notify) should be: >>>> if (bo->num_cpu_page_faults++ > 20) >>>> bo->preferred_domain = GTT_WC; >> >> I agree something like that will probably be part of the solution, but I >> doubt it's quite that simple or that it's the only thing that can be >> improved. >> >> >>> I more or less agree on that, but setting preferred_domain permanently >>> to GTT_WC is what worries me a bit. >>> >>> E.g. imagine you alt+tab from a game to your browser and back and the >>> game runs way slower now because BOs are never moved back to VRAM. >> >> Right, permanently moving a BO to GTT might itself cause performance to >> drop down a cliff in some cases. It's possible that this is irrelevant >> compared to excessive buffer migration for CPU access though. >> >> >>> What we need is a global limit of number of bytes transfered per second >>> for swap operations or something like that. >>> >>> Or maybe a timeout which says when a BO was moved (either by swapping it >>> out or by a CPU page fault) only move it back after +n jiffies or >>> something like that. >> >> I also feel like something like this will be more useful than the number >> of CPU page faults per se. But I'm curious what Marek comes up with. :) > > I don't have any better idea at the moment. It looks like John Brooks > has already solved this issue based on his IRC comments. I don't think there's "the issue" with a single solution. None of John's patches that I've tried so far help for the scenario described in the cover letter of this series. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
