On Wed, 19 May 2010 18:57:52 +0200, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Wed, May 19, 2010 at 09:06:52AM +0100, Chris Wilson wrote: > > The next adaptation I did was to clean up evict_something to add objects > > from the inactive, active&&!pinned&&!write, flushing&&!pinned, > > active&&!pinned&&write lists. This reduces the logic in evict_something to > > a single scan over the available objects in LRU order. > > Is this really worth it? I've worried about the rescanning in case there's > no suitable hole in the inactive list, too. But we're doing that also in > the current code. And the new code doesn't change the algorithmic > complexity (still O(number_of_inactive_objects)) so we're not gonna hit an > ugly corner case. I actually thought it simplified the code and really clarified the rescan logic - which is not at all obvious as it depends upon the caller as well. > Furthermore some printk instrumentation showed that for > a full cairo-perf-traces run on my i855 only three times (over the hole > run, including rescans when new stuff arrived on the inactive list) there > was no suitable hole in the inactive list. So I've stopped worrying. I can generate more... But yes, I don't think cairo-perf-trace is a sufficiently aggressive test. That was why I was trying to apply artificial memory pressure, something I am going to try and refine in future. I guess we will have to look at the games for scenarios that thrash the aperture. > I'm still crunching the numbers, but preliminary benchmarks on my i855 > show that there are _no_ regressions in cairo-traces (poppler is the only > one to take a hit of 1% which is decently below it's noise floor of 2%;). > Speedups are comparable to what you've posted on the list for your patches Excellent! -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
