Re: [PATCH 0/9] [RFC] fair-lru eviction

[Chris Wilson <chris@chris-wilson.co.uk>]

On Wed, 19 May 2010 18:57:52 +0200, Daniel Vetter <daniel@ffwll.ch> 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