On 06/03/2017 14:14, Chris Wilson wrote:
On Mon, Mar 06, 2017 at 01:49:33PM +0000, Tvrtko Ursulin wrote:
On 06/03/2017 12:48, Chris Wilson wrote:
For the moment, yes :) This was a quick hack to hide a regression - the
Oh it was a real regression and not just an optimisation for a
strange client behaviour? You should add a Fixes: tag then. And
explain in the commit what it was (the regression).
I was having that debate with myself in another thread. userspace is
clearly broken, but this excerbates the damage.
real bug fix will be breaking struct_mutex out of the shrinker, I think,
and there's some nasty behaviour to resolve when we do hit the shrinker
the whole object page-in/page-out behaviour is much, much slower than
what should be the equivalent with individual pages via shmemfs. The
bonus here is that shmemfs can avoid clearing/swapping-in the page if
knows it will be completely overwritten, which makes the patch useful on
its own merit.
So in this particular case is that becuase it is swapping out even
the untouched pages? And it started doing that recently after some
commit or what?
Remember when I said that nobody would touch pages without using them,
(and so could defer the update for the shrinker until we had the
struct_mutex) and certainly not 16GiB of written-but-unused pages on a
small box? libva happened.
Oh dear.. Ok, going back to the previous reply..
I can see the benefit of avoiding the shrinker and struct mutex but
haven't found that other benefit.
I've been rummaging in the shmem.c & co but so far haven't found
anything to explain me the possibility of it avoiding
clearing/swapping-in the pages. It looks like both our normal page
allocation and this new one boil down to the same shmem_getpage.
Could you explain what I am missing?
Also, would we have any IGT coverage for this new path? And keep a solid
amount of coverage for the old paths as well.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
