From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joonas Lahtinen Subject: Re: [PATCH 1/2] shmem: Support for registration of Driver/file owner specific ops Date: Thu, 20 Oct 2016 18:15:32 +0300 Message-ID: <1476976532.3002.6.camel@linux.intel.com> References: <1458713384-25688-1-git-send-email-akash.goel@intel.com> <1458821494.7860.9.camel@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTPS id 590886EBA8 for ; Thu, 20 Oct 2016 15:15:36 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: akash goel , Chris Wilson Cc: "Goel, Akash" , linux-mm@kvack.org, intel-gfx@lists.freedesktop.org, Hugh Dickins , Sourab Gupta List-Id: intel-gfx@lists.freedesktop.org T24ga2UsIDIwMTYtMTAtMTkgYXQgMjA6NDEgKzA1MzAsIGFrYXNoIGdvZWwgd3JvdGU6Cj4gT24g VGh1LCBNYXIgMjQsIDIwMTYgYXQgNTo0MSBQTSwgSm9vbmFzIExhaHRpbmVuCj4gPiA8am9vbmFz LmxhaHRpbmVuQGxpbnV4LmludGVsLmNvbT4gd3JvdGU6Cj4gPiBPbiBrZSwgMjAxNi0wMy0yMyBh dCAxMTozOSArMDUzMCwgYWthc2guZ29lbEBpbnRlbC5jb20gd3JvdGU6Cj4gPiA+IEBAIC0zNCwx MSArMzQsMjggQEAgc3RydWN0IHNobWVtX3NiX2luZm8gewo+ID4gPiDCoMKgwqDCoMKgwqBzdHJ1 Y3QgbWVtcG9saWN5ICptcG9sO8KgwqDCoMKgwqAvKiBkZWZhdWx0IG1lbW9yeSBwb2xpY3kgZm9y IG1hcHBpbmdzICovCj4gPiA+IMKgfTsKPiA+ID4gCj4gPiA+ICtzdHJ1Y3Qgc2htZW1fZGV2X2lu Zm8gewo+ID4gPiArwqDCoMKgwqDCoHZvaWQgKmRldl9wcml2YXRlX2RhdGE7Cj4gPiA+ICvCoMKg wqDCoMKgaW50ICgqZGV2X21pZ3JhdGVwYWdlKShzdHJ1Y3QgYWRkcmVzc19zcGFjZSAqbWFwcGlu ZywKPiA+ID4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgc3RydWN0IHBhZ2UgKm5ld3BhZ2UsIHN0cnVjdCBwYWdlICpwYWdlLAo+ID4gPiAr wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBl bnVtIG1pZ3JhdGVfbW9kZSBtb2RlLCB2b2lkICpkZXZfcHJpdl9kYXRhKTsKPiA+IAo+ID4gT25l IG1pZ2h0IHdhbnQgdG8gaGF2ZSBhIHNlcGFyYXRlIHNobWVtX2Rldl9vcGVyYXRpb25zIHN0cnVj dCBvcgo+ID4gc2ltaWxhci4KPiA+IAo+IFNvcnJ5IGZvciB0aGUgdmVyeSBsYXRlIHR1cm5hcm91 bmQuCj4gCj4gU29ycnkgY291bGRuJ3QgZ2V0IHlvdXIgcG9pbnQgaGVyZS4gQXJlIHlvdSBzdWdn ZXN0aW5nIHRvIHJlbmFtZSB0aGUKPiBzdHJ1Y3R1cmUgdG8gc2htZW1fZGV2X29wZXJhdGlvbnMg PwoKSSdtIHByZXR0eSBzdXJlIEkgd2FzIGFmdGVyIHB1dHRpbmcgbWlncmF0ZXBhZ2UgZnVuY3Rp b24gcG9pbnRlciBpbgpzaG1lbV9kZXZfb3BlcmF0aW9ucyBzdHJ1Y3QsIGJ1dCBJIHRoaW5rIHRo YXQgY2FuIGJlIGRvbmUgb25jZSB0aGVyZQphcmUgbW9yZSBmdW5jdGlvbnMuCgpzL2Rldl9wcml2 YXRlX2RhdGEvcHJpdmF0ZV9kYXRhLyBhbmQgcy9kZXZfcHJpdl9kYXRhL3ByaXZhdGVfZGF0YS8K bWlnaHQgYmUgaW4gb3JkZXIsIHRvby4gSSBzaG91bGQgYmUgb2J2aW91cyBmcm9tIGNvbnRleHQu Cgo+ID4gPiArfTsKPiA+ID4gKwo+ID4gPiDCoHN0YXRpYyBpbmxpbmUgc3RydWN0IHNobWVtX2lu b2RlX2luZm8gKlNITUVNX0koc3RydWN0IGlub2RlICppbm9kZSkKPiA+ID4gwqB7Cj4gPiA+IMKg wqDCoMKgwqDCoHJldHVybiBjb250YWluZXJfb2YoaW5vZGUsIHN0cnVjdCBzaG1lbV9pbm9kZV9p bmZvLCB2ZnNfaW5vZGUpOwo+ID4gPiDCoH0KPiA+ID4gCj4gPiA+ICtzdGF0aWMgaW5saW5lIGlu dCBzaG1lbV9zZXRfZGV2aWNlX29wcyhzdHJ1Y3QgYWRkcmVzc19zcGFjZSAqbWFwcGluZywKPiA+ ID4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqBzdHJ1Y3Qgc2htZW1fZGV2X2luZm8gKmluZm8pCj4gPiA+ICt7CgpUaGlzIG5hbWUgY291 bGQgYmUgc2htZW1fc2V0X2Rldl9pbmZvLCBpZiB0aGVyZSB3aWxsIGJlIHNlcGFyYXRlIF9vcHMK c3RydWN0IGluIGZ1dHVyZS4KCj4gPiA+ICvCoMKgwqDCoMKgaWYgKG1hcHBpbmctPnByaXZhdGVf ZGF0YSAhPSBOVUxMKQo+ID4gPiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqByZXR1cm4gLUVF WElTVDsKPiA+ID4gKwo+ID4gCj4gPiBJIGRpZCBhIHF1aWNrIHJhbmRvbSBwZWVrIGFuZCBtb3N0 IHNldCBmdW5jdGlvbnMgYXJlIGp1c3Qgdm9pZCBhbmQKPiA+IG92ZXJyaWRlIGV4aXN0aW5nIGRh dGEuIEknZCBzdWdnZXN0IHRoZSBzYW1lLgo+ID4gCj4gPiA+IAo+ID4gPiArwqDCoMKgwqDCoG1h cHBpbmctPnByaXZhdGVfZGF0YSA9IGluZm87Cj4gPiAKPiBGaW5lIHdpbGwgY2hhbmdlIHRoZSBy ZXR1cm4gdHlwZSB0byB2b2lkIGFuZCByZW1vdmUgdGhlIGNoZWNrLgo+IAo+ID4gCj4gPiBBbHNv LCBkb2Vzbid0IHRoaXMga2luZGEgc3RlYWwgdGhlIG1hcHBpbmctPnByaXZhdGVfZGF0YSwgbWln aHQgdGhhdCBiZQo+ID4gdW5leHBlY3RlZCBmb3IgdGhlIHVzZXI/IEkgbm90aWNlIGN1cnJlbnRs eSBpdCdzIG5vdCBiZWluZyB0b3VjaGVkIGF0Cj4gPiBhbGwuCj4gPiAKPiBTb3JyeSBieSBVc2Vy IGRvIHlvdSBtZWFuIHRoZSBzaG1lbSBjbGllbnQgd2hvIGNhbGxlZCBzaG1lbV9maWxlX3NldHVw KCkgPwo+IEl0IHNlZW1zIGNsaWVudHMgYXJlIG5vdCBleHBlY3RlZCB0byB0b3VjaCBtYXBwaW5n LT5wcml2YXRlX2RhdGEgYW5kCj4gc28gc2htZW1mcyBjYW4gc2FmZWx5IHVzZSBpdC4KCklmIGl0 J3Mgbm90IHVzZWQgYnkgb3RoZXJzLCBzaG91bGQgYmUgZmluZS4gTm90IHN1cmUgaWYgV0FSTiB3 b3VsZCBiZQppbiBwbGFjZSwgQ2hyaXM/CgpSZWdhcmRzLCBKb29uYXMKLS0gCkpvb25hcyBMYWh0 aW5lbgpPcGVuIFNvdXJjZSBUZWNobm9sb2d5IENlbnRlcgpJbnRlbCBDb3Jwb3JhdGlvbgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpJbnRlbC1nZnggbWFp bGluZyBsaXN0CkludGVsLWdmeEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5m cmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnRlbC1nZngK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f69.google.com (mail-it0-f69.google.com [209.85.214.69]) by kanga.kvack.org (Postfix) with ESMTP id 3BBAF6B0038 for ; Thu, 20 Oct 2016 11:15:41 -0400 (EDT) Received: by mail-it0-f69.google.com with SMTP id z65so113271984itc.2 for ; Thu, 20 Oct 2016 08:15:41 -0700 (PDT) Received: from mga06.intel.com (mga06.intel.com. [134.134.136.31]) by mx.google.com with ESMTPS id sm3si37942600pac.261.2016.10.20.08.15.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Oct 2016 08:15:36 -0700 (PDT) Message-ID: <1476976532.3002.6.camel@linux.intel.com> Subject: Re: [Intel-gfx] [PATCH 1/2] shmem: Support for registration of Driver/file owner specific ops From: Joonas Lahtinen Date: Thu, 20 Oct 2016 18:15:32 +0300 In-Reply-To: References: <1458713384-25688-1-git-send-email-akash.goel@intel.com> <1458821494.7860.9.camel@linux.intel.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: akash goel , Chris Wilson Cc: intel-gfx@lists.freedesktop.org, linux-mm@kvack.org, Hugh Dickins , Sourab Gupta , "Goel, Akash" On ke, 2016-10-19 at 20:41 +0530, akash goel wrote: > On Thu, Mar 24, 2016 at 5:41 PM, Joonas Lahtinen > > wrote: > > On ke, 2016-03-23 at 11:39 +0530, akash.goel@intel.com wrote: > > > @@ -34,11 +34,28 @@ struct shmem_sb_info { > > > A A A A A A struct mempolicy *mpol;A A A A A /* default memory policy for mappings */ > > > A }; > > > > > > +struct shmem_dev_info { > > > +A A A A A void *dev_private_data; > > > +A A A A A int (*dev_migratepage)(struct address_space *mapping, > > > +A A A A A A A A A A A A A A A A A A A A A A A A A A A A struct page *newpage, struct page *page, > > > +A A A A A A A A A A A A A A A A A A A A A A A A A A A A enum migrate_mode mode, void *dev_priv_data); > > > > One might want to have a separate shmem_dev_operations struct or > > similar. > > > Sorry for the very late turnaround. > > Sorry couldn't get your point here. Are you suggesting to rename the > structure to shmem_dev_operations ? I'm pretty sure I was after putting migratepage function pointer in shmem_dev_operations struct, but I think that can be done once there are more functions. s/dev_private_data/private_data/ and s/dev_priv_data/private_data/ might be in order, too. I should be obvious from context. > > > +}; > > > + > > > A static inline struct shmem_inode_info *SHMEM_I(struct inode *inode) > > > A { > > > A A A A A A return container_of(inode, struct shmem_inode_info, vfs_inode); > > > A } > > > > > > +static inline int shmem_set_device_ops(struct address_space *mapping, > > > +A A A A A A A A A A A A A A A A A A A A A A A A A A A A A struct shmem_dev_info *info) > > > +{ This name could be shmem_set_dev_info, if there will be separate _ops struct in future. > > > +A A A A A if (mapping->private_data != NULL) > > > +A A A A A A A A A A A A A return -EEXIST; > > > + > > > > I did a quick random peek and most set functions are just void and > > override existing data. I'd suggest the same. > > > > > > > > +A A A A A mapping->private_data = info; > > > Fine will change the return type to void and remove the check. > > > > > Also, doesn't this kinda steal the mapping->private_data, might that be > > unexpected for the user? I notice currently it's not being touched at > > all. > > > Sorry by User do you mean the shmem client who called shmem_file_setup() ? > It seems clients are not expected to touch mapping->private_data and > so shmemfs can safely use it. If it's not used by others, should be fine. Not sure if WARN would be in place, Chris? Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org