[Intel-gfx] [PATCH 1/3] drm/i915: Use pagecache write to prepopulate shmemfs from pwrite-ioctl

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Mon Mar 6 16:32:45 UTC 2017


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


More information about the Intel-gfx mailing list