Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Thomas Hellstrom <thellstrom@vmware.com>
To:     =?iso-8859-1?Q?Thomas_Hellstr=F6m_=28VMware=29?= 
        <thomas_os@shipmail.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>
CC:     "torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Matthew Wilcox <willy@infradead.org>,
        Will Deacon <will.deacon@arm.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Rik van Riel <riel@surriel.com>,
        Minchan Kim <minchan@kernel.org>,
        Michal Hocko <mhocko@suse.com>,
        Huang Ying <ying.huang@intel.com>,
        =?iso-8859-1?Q?J=E9r=F4me_Glisse?= <jglisse@redhat.com>,
        "Kirill A . Shutemov" <kirill@shutemov.name>
Subject: Re: [PATCH v6 0/8] Emulated coherent graphics memory take 2
Thread-Topic: [PATCH v6 0/8] Emulated coherent graphics memory take 2
Thread-Index: AQHVgpJqC8shh+REck6Kwu9Se+Blog==
Date:   Mon, 21 Oct 2019 12:24:45 +0000
Message-ID: <MN2PR05MB61414127631EA073C0757B78A1690@MN2PR05MB6141.namprd05.prod.outlook.com>
References: <20191014132204.7721-1-thomas_os@shipmail.org>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: vmware.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2264430e-bced-48d0-30b2-08d75621a89f
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2019 12:24:45.7559
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FD4+7LFUv4lYECDgHgFpuH23YIwGJtHyt7rYjLJVYQsiBe0SvFas57u/439jcI4jWdGvjxMlJoy8iy9Jwo18wg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB7024
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 10/14/19 3:22 PM, Thomas Hellstr=F6m (VMware) wrote:=0A=
> From: Thomas Hellstr=F6m <thellstrom@vmware.com>=0A=
>=0A=
> Graphics APIs like OpenGL 4.4 and Vulkan require the graphics driver=0A=
> to provide coherent graphics memory, meaning that the GPU sees any=0A=
> content written to the coherent memory on the next GPU operation that=0A=
> touches that memory, and the CPU sees any content written by the GPU=0A=
> to that memory immediately after any fence object trailing the GPU=0A=
> operation is signaled.=0A=
>=0A=
> Paravirtual drivers that otherwise require explicit synchronization=0A=
> needs to do this by hooking up dirty tracking to pagefault handlers=0A=
> and buffer object validation.=0A=
>=0A=
> Provide mm helpers needed for this and that also allow for huge pmd-=0A=
> and pud entries (patch 1-3), and the associated vmwgfx code (patch 4-7).=
=0A=
>=0A=
> The code has been tested and exercised by a tailored version of mesa=0A=
> where we disable all explicit synchronization and assume graphics memory=
=0A=
> is coherent. The performance loss varies of course; a typical number is=
=0A=
> around 5%.=0A=
>=0A=
> I would like to merge this code through the DRM tree, so an ack to includ=
e=0A=
> the new mm helpers in that merge would be greatly appreciated.=0A=
>=0A=
> Changes since RFC:=0A=
> - Merge conflict changes moved to the correct patch. Fixes intra-patchset=
=0A=
>   compile errors.=0A=
> - Be more aggressive when turning ttm vm code into helpers. This makes su=
re=0A=
>   we can use a const qualifier on the vmwgfx vm_ops.=0A=
> - Reinstate a lost comment an fix an error path that was broken when turn=
ing=0A=
>   the ttm vm code into helpers.=0A=
> - Remove explicit type-casts of struct vm_area_struct::vm_private_data=0A=
> - Clarify the locking inversion that makes us not being able to use the m=
m=0A=
>   pagewalk code.=0A=
>=0A=
> Changes since v1:=0A=
> - Removed the vmwgfx maintainer entry for as_dirty_helpers.c, updated=0A=
>   commit message accordingly=0A=
> - Removed the TTM patches from the series as they are merged separately=
=0A=
>   through DRM.=0A=
> Changes since v2:=0A=
> - Split out the pagewalk code from as_dirty_helpers.c and document lockin=
g.=0A=
> - Add pre_vma and post_vma callbacks to the pagewalk code.=0A=
> - Remove huge pmd and -pud asserts that would trip when we protect vmas w=
ith=0A=
>   struct address_space::i_mmap_rwsem rather than with=0A=
>   struct vm_area_struct::mmap_sem.=0A=
> - Do some naming cleanup in as_dirty_helpers.c=0A=
> Changes since v3:=0A=
> - Extensive renaming of the dirty helpers including the filename.=0A=
> - Update walk_page_mapping() doc.=0A=
> - Update the pagewalk code to not unconditionally split pmds if a pte_ent=
ry()=0A=
>   callback is present. Update the dirty helper pmd_entry accordingly.=0A=
> - Use separate walk ops for the dirty helpers.=0A=
> - Update the pagewalk code to take the pagetable lock in walk_pte_range.=
=0A=
> Changes since v4:=0A=
> - Fix pte pointer confusion in patch 2/8=0A=
> - Skip the pagewalk code conditional split patch for now, and update the=
=0A=
>   mapping_dirty_helper accordingly. That problem will be solved in a clea=
ner=0A=
>   way in a follow-up patchset.=0A=
> Changes since v5:=0A=
> - Fix tlb flushing when we have other pending tlb flushes.=0A=
>   =0A=
> Cc: Andrew Morton <akpm@linux-foundation.org>=0A=
> Cc: Matthew Wilcox <willy@infradead.org>=0A=
> Cc: Will Deacon <will.deacon@arm.com>=0A=
> Cc: Peter Zijlstra <peterz@infradead.org>=0A=
> Cc: Rik van Riel <riel@surriel.com>=0A=
> Cc: Minchan Kim <minchan@kernel.org>=0A=
> Cc: Michal Hocko <mhocko@suse.com>=0A=
> Cc: Huang Ying <ying.huang@intel.com>=0A=
> Cc: J=E9r=F4me Glisse <jglisse@redhat.com>=0A=
> Cc: Kirill A. Shutemov <kirill@shutemov.name>=0A=
>=0A=
Kirill, Linus=0A=
=0A=
I have a formal Ack for two of the four mm patches. Is there a chance I=0A=
can get an ack to merge the mm patches of this series through drm with=0A=
the vmwgfx patches?=0A=
=0A=
Thanks,=0A=
=0A=
Thomas=0A=
=0A=
=0A=