From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Williams Subject: Re: [PATCH v4 0/9] mmu notifier provide context informations Date: Wed, 23 Jan 2019 16:00:37 -0800 Message-ID: References: <20190123222315.1122-1-jglisse@redhat.com> <20190123230447.GC1257@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20190123230447.GC1257@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Jerome Glisse Cc: Ralph Campbell , Jan Kara , Arnd Bergmann , KVM list , Matthew Wilcox , linux-rdma , John Hubbard , Felix Kuehling , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Linux Kernel Mailing List , Maling list - DRI developers , Michal Hocko , Linux MM , Jason Gunthorpe , Ross Zwisler , linux-fsdevel , Paolo Bonzini , Andrew Morton , =?UTF-8?Q?Christian_K=C3=B6nig?= List-Id: linux-rdma@vger.kernel.org T24gV2VkLCBKYW4gMjMsIDIwMTkgYXQgMzowNSBQTSBKZXJvbWUgR2xpc3NlIDxqZ2xpc3NlQHJl ZGhhdC5jb20+IHdyb3RlOgo+Cj4gT24gV2VkLCBKYW4gMjMsIDIwMTkgYXQgMDI6NTQ6NDBQTSAt MDgwMCwgRGFuIFdpbGxpYW1zIHdyb3RlOgo+ID4gT24gV2VkLCBKYW4gMjMsIDIwMTkgYXQgMjoy MyBQTSA8amdsaXNzZUByZWRoYXQuY29tPiB3cm90ZToKPiA+ID4KPiA+ID4gRnJvbTogSsOpcsO0 bWUgR2xpc3NlIDxqZ2xpc3NlQHJlZGhhdC5jb20+Cj4gPiA+Cj4gPiA+IEhpIEFuZHJldywgaSBz ZWUgdGhhdCB5b3Ugc3RpbGwgaGF2ZSBteSBldmVudCBwYXRjaCBpbiB5b3UgcXVldWUgWzFdLgo+ ID4gPiBUaGlzIHBhdGNoc2V0IHJlcGxhY2UgdGhhdCBzaW5nbGUgcGF0Y2ggYW5kIGlzIGJyb2tl biBkb3duIGluIGZ1cnRoZXIKPiA+ID4gc3RlcCBzbyB0aGF0IGl0IGlzIGVhc2llciB0byByZXZp ZXcgYW5kIGFzY2VydGFpbiB0aGF0IG5vIG1pc3Rha2Ugd2VyZQo+ID4gPiBtYWRlIGR1cmluZyBt ZWNoYW5pY2FsIGNoYW5nZXMuIEhlcmUgYXJlIHRoZSBzdGVwOgo+ID4gPgo+ID4gPiAgICAgUGF0 Y2ggMSAtIGFkZCB0aGUgZW51bSB2YWx1ZXMKPiA+ID4gICAgIFBhdGNoIDIgLSBjb2NjaW5lbGxl IHNlbWFudGljIHBhdGNoIHRvIGNvbnZlcnQgYWxsIGNhbGwgc2l0ZSBvZgo+ID4gPiAgICAgICAg ICAgICAgIG1tdV9ub3RpZmllcl9yYW5nZV9pbml0IHRvIGRlZmF1bHQgZW51bSB2YWx1ZSBhbmQg YWxzbwo+ID4gPiAgICAgICAgICAgICAgIHRvIHBhc3NpbmcgZG93biB0aGUgdm1hIHdoZW4gaXQg aXMgYXZhaWxhYmxlCj4gPiA+ICAgICBQYXRjaCAzIC0gdXBkYXRlIG1hbnkgY2FsbCBzaXRlIHRv IG1vcmUgYWNjdXJhdGUgZW51bSB2YWx1ZXMKPiA+ID4gICAgIFBhdGNoIDQgLSBhZGQgdGhlIGlu Zm9ybWF0aW9uIHRvIHRoZSBtbXVfbm90aWZpZXJfcmFuZ2Ugc3RydWN0Cj4gPiA+ICAgICBQYXRj aCA1IC0gaGVscGVyIHRvIHRlc3QgaWYgYSByYW5nZSBpcyB1cGRhdGVkIHRvIHJlYWQgb25seQo+ ID4gPgo+ID4gPiBBbGwgdGhlIHJlbWFpbmluZyBwYXRjaGVzIGFyZSB1cGRhdGUgdG8gdmFyaW91 cyBkcml2ZXIgdG8gZGVtb25zdHJhdGUKPiA+ID4gaG93IHRoaXMgbmV3IGluZm9ybWF0aW9uIGdl dCB1c2UgYnkgZGV2aWNlIGRyaXZlci4gSSBidWlsZCB0ZXN0ZWQKPiA+ID4gd2l0aCBtYWtlIGFs bCBhbmQgbWFrZSBhbGwgbWludXMgZXZlcnl0aGluZyB0aGF0IGVuYWJsZSBtbXUgbm90aWZpZXIK PiA+ID4gaWUgYnVpbGRpbmcgd2l0aCBNTVVfTk9USUZJRVI9bm8uIEFsc28gdGVzdGVkIHdpdGgg c29tZSByYWRlb24sYW1kCj4gPiA+IGdwdSBhbmQgaW50ZWwgZ3B1Lgo+ID4gPgo+ID4gPiBJZiB0 aGV5IGFyZSBubyBvYmplY3Rpb25zIGkgYmVsaWV2ZSBiZXN0IHBsYW4gd291bGQgYmUgdG8gbWVy Z2UgdGhlCj4gPiA+IHRoZSBmaXJzdCA1IHBhdGNoZXMgKGFsbCBtbSBjaGFuZ2VzKSB0aHJvdWdo IHlvdXIgcXVldWUgZm9yIDUuMSBhbmQKPiA+ID4gdGhlbiB0byBkZWxheSBkcml2ZXIgdXBkYXRl IHRvIGVhY2ggaW5kaXZpZHVhbCBkcml2ZXIgdHJlZSBmb3IgNS4yLgo+ID4gPiBUaGlzIHdpbGwg YWxsb3cgZWFjaCBpbmRpdmlkdWFsIGRldmljZSBkcml2ZXIgbWFpbnRhaW5lciB0aW1lIHRvIG1v cmUKPiA+ID4gdGhvdXJvdWdobHkgdGVzdCB0aGlzIG1vcmUgdGhlbiBteSBvd24gdGVzdGluZy4K PiA+ID4KPiA+ID4gTm90ZSB0aGF0IGkgYWxzbyBpbnRlbmQgdG8gdXNlIHRoaXMgZmVhdHVyZSBm dXJ0aGVyIGluIG5vdXZlYXUgYW5kCj4gPiA+IEhNTSBkb3duIHRoZSByb2FkLiBJIGFsc28gZXhw ZWN0IHRoYXQgb3RoZXIgdXNlciBsaWtlIEtWTSBtaWdodCBiZQo+ID4gPiBpbnRlcmVzdGVkIGlu dG8gbGV2ZXJhZ2luZyB0aGlzIG5ldyBpbmZvcm1hdGlvbiB0byBvcHRpbWl6ZSBzb21lIG9mCj4g PiA+IHRoZXJlIHNlY29uZGFyeSBwYWdlIHRhYmxlIGludmFsaWRhdGlvbi4KPiA+Cj4gPiAiRG93 biB0aGUgcm9hZCIgdXNlcnMgc2hvdWxkIGludHJvZHVjZSB0aGUgZnVuY3Rpb25hbGl0eSB0aGV5 IHdhbnQgdG8KPiA+IGNvbnN1bWUuIFRoZSBjb21tb24gY29uY2VybiB3aXRoIHByZWVtcHRpdmVs eSBpbmNsdWRpbmcKPiA+IGZvcndhcmQtbG9va2luZyBpbmZyYXN0cnVjdHVyZSBpcyByZWFsaXpp bmcgbGF0ZXIgdGhhdCB0aGUKPiA+IGluZnJhc3RydWN0dXJlIGlzIG5vdCBuZWVkZWQsIG9yIG5l ZWRzIGNoYW5naW5nLiBJZiBpdCBoYXMgbm8gY3VycmVudAo+ID4gY29uc3VtZXIsIGxlYXZlIGl0 IG91dC4KPgo+IFRoaXMgcGF0Y2hzZXQgYWxyZWFkeSBzaG93IHRoYXQgdGhpcyBpcyB1c2VmdWws IHdoYXQgbW9yZSBjYW4gaSBkbyA/Cj4gSSBrbm93IGkgd2lsbCB1c2UgdGhpcyBpbmZvcm1hdGlv biwgaW4gbm91dmVhdSBmb3IgbWVtb3J5IHBvbGljeSB3ZQo+IGFsbG9jYXRlIG91ciBvd24gc3Ry dWN0dXJlIGZvciBldmVyeSB2bWEgdGhlIEdQVSBldmVyIGFjY2Vzc2VkIG9yIHRoYXQKPiB1c2Vy c3BhY2UgaGludGVkIHdlIHNob3VsZCBzZXQgYSBwb2xpY3kgZm9yLiBSaWdodCBub3cgd2l0aCBl eGlzdGluZwo+IG1tdSBub3RpZmllciBpIF9tdXN0XyBmcmVlIHRob3NlIHN0cnVjdHVyZSBiZWNh dXNlIGkgZG8gbm90IGtub3cgaWYKPiB0aGUgaW52YWxpZGF0aW9uIGlzIGFuIG11bm1hcCBvciBz b21ldGhpbmcgZWxzZS4gU28gaSBhbSBsb29zaW5nCj4gaW1wb3J0YW50IGluZm9ybWF0aW9ucyBh bmQgdW5lY2Vzc2FybHkgZnJlZSBzdHJ1Y3QgdGhhdCBpIHdpbGwgaGF2ZQo+IHRvIHJlLWFsbG9j YXRlIGp1c3QgY291cGxlIGppZmZpZXMgbGF0dGVyLiBUaGF0J3Mgb25lIHdheSBpIGFtIHVzaW5n Cj4gdGhpcy4KClVuZGVyc3Rvb2QsIGJ1dCB0aGF0IHN0aWxsIHNlZW1zIHRvIHNheSBzdGFnZSB0 aGUgY29yZSBzdXBwb3J0IHdoZW4KdGhlIG5vdXZlYXUgZW5hYmxpbmcgaXMgcmVhZHkuCgo+IFRo ZSBvdGhlciB3YXkgaXMgdG8gb3B0aW1pemUgR1BVIHBhZ2UgdGFibGUgdXBkYXRlIGp1c3QgbGlr ZSBpCj4gYW0gZG9pbmcgd2l0aCBhbGwgdGhlIHBhdGNoZXMgdG8gUkRNQS9PRFAgYW5kIHZhcmlv dXMgR1BVIGRyaXZlcnMuCgpZZXMuCgo+Cj4KPiA+ID4gSGVyZSBpcyBhbiBleHBsYWluYXRpb24g b24gdGhlIHJhdGlvbmFsIGZvciB0aGlzIHBhdGNoc2V0Ogo+ID4gPgo+ID4gPgo+ID4gPiBDUFUg cGFnZSB0YWJsZSB1cGRhdGUgY2FuIGhhcHBlbnMgZm9yIG1hbnkgcmVhc29ucywgbm90IG9ubHkg YXMgYSByZXN1bHQKPiA+ID4gb2YgYSBzeXNjYWxsIChtdW5tYXAoKSwgbXByb3RlY3QoKSwgbXJl bWFwKCksIG1hZHZpc2UoKSwgLi4uKSBidXQgYWxzbwo+ID4gPiBhcyBhIHJlc3VsdCBvZiBrZXJu ZWwgYWN0aXZpdGllcyAobWVtb3J5IGNvbXByZXNzaW9uLCByZWNsYWltLCBtaWdyYXRpb24sCj4g PiA+IC4uLikuCj4gPiA+Cj4gPiA+IFRoaXMgcGF0Y2ggaW50cm9kdWNlIGEgc2V0IG9mIGVudW1z IHRoYXQgY2FuIGJlIGFzc29jaWF0ZWQgd2l0aCBlYWNoIG9mCj4gPiA+IHRoZSBldmVudHMgdHJp Z2dlcmluZyBhIG1tdSBub3RpZmllci4gTGF0dGVyIHBhdGNoZXMgdGFrZSBhZHZhbnRhZ2VzIG9m Cj4gPiA+IHRob3NlIGVudW0gdmFsdWVzLgo+ID4gPgo+ID4gPiAtIFVOTUFQOiBtdW5tYXAoKSBv ciBtcmVtYXAoKQo+ID4gPiAtIENMRUFSOiBwYWdlIHRhYmxlIGlzIGNsZWFyZWQgKG1pZ3JhdGlv biwgY29tcGFjdGlvbiwgcmVjbGFpbSwgLi4uKQo+ID4gPiAtIFBST1RFQ1RJT05fVk1BOiBjaGFu Z2UgaW4gYWNjZXNzIHByb3RlY3Rpb25zIGZvciB0aGUgcmFuZ2UKPiA+ID4gLSBQUk9URUNUSU9O X1BBR0U6IGNoYW5nZSBpbiBhY2Nlc3MgcHJvdGVjdGlvbnMgZm9yIHBhZ2UgaW4gdGhlIHJhbmdl Cj4gPiA+IC0gU09GVF9ESVJUWTogc29mdCBkaXJ0eW5lc3MgdHJhY2tpbmcKPiA+ID4KPiA+ID4g QmVpbmcgYWJsZSB0byBpZGVudGlmeSBtdW5tYXAoKSBhbmQgbXJlbWFwKCkgZnJvbSBvdGhlciBy ZWFzb25zIHdoeSB0aGUKPiA+ID4gcGFnZSB0YWJsZSBpcyBjbGVhcmVkIGlzIGltcG9ydGFudCB0 byBhbGxvdyB1c2VyIG9mIG1tdSBub3RpZmllciB0bwo+ID4gPiB1cGRhdGUgdGhlaXIgb3duIGlu dGVybmFsIHRyYWNraW5nIHN0cnVjdHVyZSBhY2NvcmRpbmdseSAob24gbXVubWFwIG9yCj4gPiA+ IG1yZW1hcCBpdCBpcyBub3QgbG9uZ2VyIG5lZWRlZCB0byB0cmFjayByYW5nZSBvZiB2aXJ0dWFs IGFkZHJlc3MgYXMgaXQKPiA+ID4gYmVjb21lcyBpbnZhbGlkKS4KPiA+Cj4gPiBUaGUgb25seSBj b250ZXh0IGluZm9ybWF0aW9uIGNvbnN1bWVkIGluIHRoaXMgcGF0Y2ggc2V0IGlzCj4gPiBNTVVf Tk9USUZZX1BST1RFQ1RJT05fVk1BLgo+ID4KPiA+IFdoYXQgaXMgdGhlIHByYWN0aWNhbCBiZW5l Zml0IG9mIHRoZXNlICJvcHRpbWl6ZSBvdXQgdGhlIGNhc2Ugd2hlbiBhCj4gPiByYW5nZSBpcyB1 cGRhdGVkIHRvIHJlYWQgb25seSIgb3B0aW1pemF0aW9ucz8gQW55IG51bWJlcnMgdG8gc2hvdyB0 aGlzCj4gPiBpcyB3b3J0aCB0aGUgY29kZSB0aHJhc2g/Cj4KPiBJdCBkZXBlbmRzIG9uIHRoZSB3 b3JrbG9hZCBmb3IgaW5zdGFuY2UgaWYgeW91IG1hcCB0byBSRE1BIGEgZmlsZQo+IHJlYWQgb25s eSBsaWtlIGEgbG9nIGZpbGUgZm9yIGV4cG9ydCwgYWxsIHdyaXRlIGJhY2sgdGhhdCB3b3VsZAo+ IGRpc3J1cHQgdGhlIFJETUEgbWFwcGluZyBjYW4gYmUgb3B0aW1pemVkIG91dC4KPgo+IFNlZSBh Ym92ZSBmb3IgbW9yZSByZWFzb25zIHdoeSBpdCBpcyBiZW5lZmljaWFsIChrbm93aW5nIHdoZW4g aXQgaXMKPiBhbiBtdW5tYXAvbXJlbWFwIHZlcnN1cyBzb21ldGhpbmcgZWxzZSkuCj4KPiBJIHdv dWxkIGhhdmUgbm90IHRob3VnaHQgdGhhdCBwYXNzaW5nIGRvd24gaW5mb3JtYXRpb24gYXMgc29t ZXRoaW5nCj4gdGhhdCBjb250cm92ZXJzaWFsLiBIb3BlcyB0aGlzIGhlbHAgeW91IHNlZSB0aGUg YmVuZWZpdCBvZiB0aGlzLgoKSSdtIG5vdCBhc3NlcnRpbmcgdGhhdCBpdCBpcyBjb250cm92ZXJz aWFsLiBJIGFtIGFzc2VydGluZyB0aGF0CndoZW5ldmVyIGEgY2hhbmdlbG9nIHNheXMgIm9wdGlt aXplIiBpdCBhbHNvIGluY2x1ZGVzIGNvbmNyZXRlIGRhdGEKYWJvdXQgdGhlIG9wdGltaXphdGlv biBzY2VuYXJpby4gTWF5YmUgdGhlIHNjZW5hcmlvcyB5b3UgaGF2ZQpvcHRpbWl6ZWQgYXJlIGNs ZWFyIHRvIHRoZSBkcml2ZXIgb3duZXJzLCB0aGV5IGp1c3Qgd2VyZW4ndAppbW1lZGlhdGVseSBj bGVhciB0byBtZS4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3Jn Cmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4E72C282C0 for ; Thu, 24 Jan 2019 00:00:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 887FC218A1 for ; Thu, 24 Jan 2019 00:00:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="sPIFgt6m" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726997AbfAXAAu (ORCPT ); Wed, 23 Jan 2019 19:00:50 -0500 Received: from mail-oi1-f196.google.com ([209.85.167.196]:46359 "EHLO mail-oi1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726168AbfAXAAt (ORCPT ); Wed, 23 Jan 2019 19:00:49 -0500 Received: by mail-oi1-f196.google.com with SMTP id x202so3371991oif.13 for ; Wed, 23 Jan 2019 16:00:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rpP/0N8IbDs89n8LEoHdcPYBMTkV8MXEOUkDVjHKx1E=; b=sPIFgt6mf/MIVELnlkxPQvAWnaLeYl5UwbNxfpdRhKn6kqQS3SsikKsrdPcq4QgmYC GMh/PT3pWTpAXr7c50jmmbCHibKyQe9IcHc9QgipXtasVIZXY07nyyAV4+leQjipIw4R 7cYfA4hrW+gIpu83Q3wgMfQ6+M4lOw13h3s33wOL0hoWe/ZICQcSKSDqhHXMmQ4TB4zd DwWxN5cR0lqpAR+0fB2Giz1uM2tAFc+UvwGOLDTHTjdBjbs16DnvRk8BtyUhiai2DUZW 56qF7+vPd4ISuy3nXpyCxFBG5PG642P6IuzMVZVHeovipm5zR4PrN8POdD4IH3Epckcj sUdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rpP/0N8IbDs89n8LEoHdcPYBMTkV8MXEOUkDVjHKx1E=; b=QJWZGKNeJsAILZVH/yFmgunakgGe0qlB1s4X6md2grpOq1FPwgliJXiarH2MHGAMrL juiRk1bUM/wl1QQulKdHkJk1RszcFN66NYj/VMz3QjSUdXhSvnFG1POr4deaupG1ZJe5 mfsKWQE2WEHZnMLKOM8/hxRQ0U/cOeq+doPhFMHTQm9qFOI+FJt1n4j32UZM8NY2P31R 3OwET5ikIhJxlDVPWPI0aOuPxm2ud7BjTMlVFrcnpsGQtzZUMJPc+PDB9r9dKlsU+QD0 6Y71cH8iWjRtGxHCZhDxb3hDfiQw7UO/MvUdglK7nvfZAmCPcEj0LUfbrGvLB1PlJOF1 070A== X-Gm-Message-State: AJcUukfIsxiMs2uJxyUqhtUO9RdCwLtgqX6Ygdo0RyqZ+NCPuBUGzhN6 Tl12WB+IOOxfDKn7T16W34TP0w8no+yVG4FSbU5Uww== X-Google-Smtp-Source: ALg8bN7gocapdWlDuMxCMzOUkT08yZ0mDyICKGp1Ug3fEDQ+F9y73yh31xTG9r9DQbg5Qkm1gE2RU8ScZbB4cgsamcw= X-Received: by 2002:aca:f4c2:: with SMTP id s185mr2810213oih.244.1548288048338; Wed, 23 Jan 2019 16:00:48 -0800 (PST) MIME-Version: 1.0 References: <20190123222315.1122-1-jglisse@redhat.com> <20190123230447.GC1257@redhat.com> In-Reply-To: <20190123230447.GC1257@redhat.com> From: Dan Williams Date: Wed, 23 Jan 2019 16:00:37 -0800 Message-ID: Subject: Re: [PATCH v4 0/9] mmu notifier provide context informations To: Jerome Glisse Cc: Ralph Campbell , Jan Kara , Arnd Bergmann , KVM list , Matthew Wilcox , linux-rdma , John Hubbard , Felix Kuehling , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Linux Kernel Mailing List , Maling list - DRI developers , Michal Hocko , Linux MM , Jason Gunthorpe , Ross Zwisler , linux-fsdevel , Paolo Bonzini , Andrew Morton , =?UTF-8?Q?Christian_K=C3=B6nig?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 23, 2019 at 3:05 PM Jerome Glisse wrote: > > On Wed, Jan 23, 2019 at 02:54:40PM -0800, Dan Williams wrote: > > On Wed, Jan 23, 2019 at 2:23 PM wrote: > > > > > > From: J=C3=A9r=C3=B4me Glisse > > > > > > Hi Andrew, i see that you still have my event patch in you queue [1]. > > > This patchset replace that single patch and is broken down in further > > > step so that it is easier to review and ascertain that no mistake wer= e > > > made during mechanical changes. Here are the step: > > > > > > Patch 1 - add the enum values > > > Patch 2 - coccinelle semantic patch to convert all call site of > > > mmu_notifier_range_init to default enum value and also > > > to passing down the vma when it is available > > > Patch 3 - update many call site to more accurate enum values > > > Patch 4 - add the information to the mmu_notifier_range struct > > > Patch 5 - helper to test if a range is updated to read only > > > > > > All the remaining patches are update to various driver to demonstrate > > > how this new information get use by device driver. I build tested > > > with make all and make all minus everything that enable mmu notifier > > > ie building with MMU_NOTIFIER=3Dno. Also tested with some radeon,amd > > > gpu and intel gpu. > > > > > > If they are no objections i believe best plan would be to merge the > > > the first 5 patches (all mm changes) through your queue for 5.1 and > > > then to delay driver update to each individual driver tree for 5.2. > > > This will allow each individual device driver maintainer time to more > > > thouroughly test this more then my own testing. > > > > > > Note that i also intend to use this feature further in nouveau and > > > HMM down the road. I also expect that other user like KVM might be > > > interested into leveraging this new information to optimize some of > > > there secondary page table invalidation. > > > > "Down the road" users should introduce the functionality they want to > > consume. The common concern with preemptively including > > forward-looking infrastructure is realizing later that the > > infrastructure is not needed, or needs changing. If it has no current > > consumer, leave it out. > > This patchset already show that this is useful, what more can i do ? > I know i will use this information, in nouveau for memory policy we > allocate our own structure for every vma the GPU ever accessed or that > userspace hinted we should set a policy for. Right now with existing > mmu notifier i _must_ free those structure because i do not know if > the invalidation is an munmap or something else. So i am loosing > important informations and unecessarly free struct that i will have > to re-allocate just couple jiffies latter. That's one way i am using > this. Understood, but that still seems to say stage the core support when the nouveau enabling is ready. > The other way is to optimize GPU page table update just like i > am doing with all the patches to RDMA/ODP and various GPU drivers. Yes. > > > > > Here is an explaination on the rational for this patchset: > > > > > > > > > CPU page table update can happens for many reasons, not only as a res= ult > > > of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but als= o > > > as a result of kernel activities (memory compression, reclaim, migrat= ion, > > > ...). > > > > > > This patch introduce a set of enums that can be associated with each = of > > > the events triggering a mmu notifier. Latter patches take advantages = of > > > those enum values. > > > > > > - UNMAP: munmap() or mremap() > > > - CLEAR: page table is cleared (migration, compaction, reclaim, ...) > > > - PROTECTION_VMA: change in access protections for the range > > > - PROTECTION_PAGE: change in access protections for page in the range > > > - SOFT_DIRTY: soft dirtyness tracking > > > > > > Being able to identify munmap() and mremap() from other reasons why t= he > > > page table is cleared is important to allow user of mmu notifier to > > > update their own internal tracking structure accordingly (on munmap o= r > > > mremap it is not longer needed to track range of virtual address as i= t > > > becomes invalid). > > > > The only context information consumed in this patch set is > > MMU_NOTIFY_PROTECTION_VMA. > > > > What is the practical benefit of these "optimize out the case when a > > range is updated to read only" optimizations? Any numbers to show this > > is worth the code thrash? > > It depends on the workload for instance if you map to RDMA a file > read only like a log file for export, all write back that would > disrupt the RDMA mapping can be optimized out. > > See above for more reasons why it is beneficial (knowing when it is > an munmap/mremap versus something else). > > I would have not thought that passing down information as something > that controversial. Hopes this help you see the benefit of this. I'm not asserting that it is controversial. I am asserting that whenever a changelog says "optimize" it also includes concrete data about the optimization scenario. Maybe the scenarios you have optimized are clear to the driver owners, they just weren't immediately clear to me.