From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
To: "mpatocka@redhat.com" <mpatocka@redhat.com>
Cc: "linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
"ladis@linux-mips.org" <ladis@linux-mips.org>,
"b.zolnierkie@samsung.com" <b.zolnierkie@samsung.com>,
"bernie@plugable.com" <bernie@plugable.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
Evgeniy Didin <Evgeniy.Didin@synopsys.com>,
"airlied@redhat.com" <airlied@redhat.com>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>
Subject: Re: [PATCH 08/21] udl-kms: avoid prefetch
Date: Fri, 15 Jun 2018 16:30:01 +0000 [thread overview]
Message-ID: <c00416da8a1fd5bb3678b5eb6148fcc631848367.camel@synopsys.com> (raw)
In-Reply-To: <alpine.LRH.2.02.1806061138080.7464@file01.intranet.prod.int.rdu2.redhat.com>
SGkgTWlrdWxhcywNCg0KT24gV2VkLCAyMDE4LTA2LTA2IGF0IDExOjQ2IC0wNDAwLCBNaWt1bGFz
IFBhdG9ja2Egd3JvdGU6DQo+IA0KPiBPbiBXZWQsIDYgSnVuIDIwMTgsIEFsZXhleSBCcm9ka2lu
IHdyb3RlOg0KPiANCj4gPiBIaSBNaWt1bGFzLA0KPiA+IA0KPiA+IE9uIFR1ZSwgMjAxOC0wNi0w
NSBhdCAxMTozMCAtMDQwMCwgTWlrdWxhcyBQYXRvY2thIHdyb3RlOg0KPiA+ID4gDQo+ID4gPiBP
biBUdWUsIDUgSnVuIDIwMTgsIEFsZXhleSBCcm9ka2luIHdyb3RlOg0KPiA+ID4gDQo+ID4gPiA+
IEhpIE1pa3VsYXMsDQo+ID4gPiA+IA0KPiA+ID4gPiBPbiBTdW4sIDIwMTgtMDYtMDMgYXQgMTY6
NDEgKzAyMDAsIE1pa3VsYXMgUGF0b2NrYSB3cm90ZToNCj4gPiA+ID4gPiBNb2Rlcm4gcHJvY2Vz
c29ycyBjYW4gZGV0ZWN0IGxpbmVhciBtZW1vcnkgYWNjZXNzZXMgYW5kIHByZWZldGNoIGRhdGEN
Cj4gPiA+ID4gPiBhdXRvbWF0aWNhbGx5LCBzbyB0aGVyZSdzIG5vIG5lZWQgdG8gdXNlIHByZWZl
dGNoLg0KPiA+ID4gPiANCj4gPiA+ID4gTm90IGVhY2ggYW5kIGV2ZXJ5IENQVSB0aGF0J3MgY2Fw
YWJsZSBvZiBydW5uaW5nIExpbnV4IGhhcyBwcmVmZXRjaA0KPiA+ID4gPiBmdW5jdGlvbmFsaXR5
IDopDQo+ID4gPiA+IA0KPiA+ID4gPiBTdGlsbCByZWFkLW9uLi4uDQo+ID4gPiA+IA0KPiA+ID4g
PiA+IFNpZ25lZC1vZmYtYnk6IE1pa3VsYXMgUGF0b2NrYSA8bXBhdG9ja2FAcmVkaGF0LmNvbT4N
Cj4gPiA+ID4gPiANCj4gPiA+ID4gPiAtLS0NCj4gPiA+ID4gPiAgZHJpdmVycy9ncHUvZHJtL3Vk
bC91ZGxfdHJhbnNmZXIuYyB8ICAgIDcgLS0tLS0tLQ0KPiA+ID4gPiA+ICAxIGZpbGUgY2hhbmdl
ZCwgNyBkZWxldGlvbnMoLSkNCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBJbmRleDogbGludXgtNC4x
Ni4xMi9kcml2ZXJzL2dwdS9kcm0vdWRsL3VkbF90cmFuc2Zlci5jDQo+ID4gPiA+ID4gPT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PQ0KPiA+ID4gPiA+IC0tLSBsaW51eC00LjE2LjEyLm9yaWcvZHJpdmVycy9ncHUvZHJtL3Vk
bC91ZGxfdHJhbnNmZXIuYwkyMDE4LTA1LTMxIDE0OjQ4OjEyLjAwMDAwMDAwMCArMDIwMA0KPiA+
ID4gPiA+ICsrKyBsaW51eC00LjE2LjEyL2RyaXZlcnMvZ3B1L2RybS91ZGwvdWRsX3RyYW5zZmVy
LmMJMjAxOC0wNS0zMSAxNDo0ODoxMi4wMDAwMDAwMDAgKzAyMDANCj4gPiA+ID4gPiBAQCAtMTMs
NyArMTMsNiBAQA0KPiA+ID4gPiA+ICAjaW5jbHVkZSA8bGludXgvbW9kdWxlLmg+DQo+ID4gPiA+
ID4gICNpbmNsdWRlIDxsaW51eC9zbGFiLmg+DQo+ID4gPiA+ID4gICNpbmNsdWRlIDxsaW51eC9m
Yi5oPg0KPiA+ID4gPiA+IC0jaW5jbHVkZSA8bGludXgvcHJlZmV0Y2guaD4NCj4gPiA+ID4gPiAg
I2luY2x1ZGUgPGFzbS91bmFsaWduZWQuaD4NCj4gPiA+ID4gPiAgDQo+ID4gPiA+ID4gICNpbmNs
dWRlIDxkcm0vZHJtUC5oPg0KPiA+ID4gPiA+IEBAIC01MSw5ICs1MCw2IEBAIHN0YXRpYyBpbnQg
dWRsX3RyaW1faGxpbmUoY29uc3QgdTggKmJiYWMNCj4gPiA+ID4gPiAgCWludCBzdGFydCA9IHdp
ZHRoOw0KPiA+ID4gPiA+ICAJaW50IGVuZCA9IHdpZHRoOw0KPiA+ID4gPiA+ICANCj4gPiA+ID4g
PiAtCXByZWZldGNoKCh2b2lkICopIGZyb250KTsNCj4gPiA+ID4gPiAtCXByZWZldGNoKCh2b2lk
ICopIGJhY2spOw0KPiA+ID4gPiANCj4gPiA+ID4gQUZBSUsgcHJlZmV0Y2hlciBmZXRjaGVzIG5l
dyBkYXRhIGFjY29yZGluZyB0byBhIGtub3duIGhpc3RvcnkuLi4gaS5lLiBiYXNlZCBvbiBwcmV2
aW91c2x5DQo+ID4gPiA+IHVzZWQgcGF0dGVybiB3ZSdsbCB0cnlpbmcgdG8gZ2V0IHRoZSBuZXh0
IGJhdGNoIG9mIGRhdGEuDQo+ID4gPiA+IA0KPiA+ID4gPiBCdXQgdGhlIGNvZGUgYWJvdmUgaXMg
aW4gdGhlIHZlcnkgYmVnaW5uaW5nIG9mIHRoZSBkYXRhIHByb2Nlc3Npbmcgcm91dGluZSB3aGVy
ZQ0KPiA+ID4gPiBwcmVmZXRjaGVyIGRvZXNuJ3QgeWV0IGhhdmUgYW55IGhpc3RvcnkgdG8ga25v
dyB3aGF0IGFuZCB3aGVyZSB0byBwcmVmZXRjaC4NCj4gPiA+ID4gDQo+ID4gPiA+IFNvIEknZCBz
YXkgdGhpcyBwYXJ0aWN1bGFyIHVzYWdlIGlzIGdvb2QuDQo+ID4gPiA+IEF0IGxlYXN0IHRob3Nl
IHByZWZldGNoZXMgc2hvdWxkbid0IGh1cnQgYmVjYXVzZSB0eXBpY2FsbHkgaXQNCj4gPiA+ID4g
d291bGQgYmUganVzdCAxIGluc3RydWN0aW9uIGlmIHRob3NlIGV4aXN0IG9yIG5vdGhpbmcgaWYg
Q1BVL2NvbXBpbGVyIGRvZXNuJ3QNCj4gPiA+ID4gc3VwcG9ydCBpdC4NCj4gPiA+IA0KPiA+ID4g
U2VlIHRoaXMgcG9zdCBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9
aHR0cHMtM0FfX2x3bi5uZXRfQXJ0aWNsZXNfNDQ0MzM2XyZkPUR3SUJBZyZjPURQTDZfWF82SmtY
Rng3QVhXcUIwdGcmcj1scWRlZVNTRWVzMEdGRERsDQo+ID4gPiA2NTZlDQo+ID4gPiBWaVhPN2Jy
ZVM1NXl0V2tocGs1UjgxSSZtPWE1UmFxSnR2YWpGa00xaEw3Yk9LRDVqVjdjcEZmVHZHMlkxY1lD
ZEJQZDAmcz13MFc4d0Z0QWdFTnA4VEU2UnpkUEdoZEtSYXNKY19vdEluMDhWMEVrZ3JZJmU9IHdo
ZXJlIHRoZXkgbWVhc3VyZWQgdGhhdCANCj4gPiA+IHByZWZldGNoIGh1cnRzIHBlcmZvcm1hbmNl
LiBQcmVmZXRjaCBzaG91bGRuJ3QgYmUgdXNlZCB1bmxlc3MgeW91IGhhdmUgYSANCj4gPiA+IHBy
b29mIHRoYXQgaXQgaW1wcm92ZXMgcGVyZm9ybWFuY2UuDQo+ID4gPiANCj4gPiA+IFRoZSBwcm9i
bGVtIGlzIHRoYXQgdGhlIHByZWZldGNoIGluc3RydWN0aW9uIGNhdXNlcyBzdGFsbHMgaW4gdGhl
IHBpcGVsaW5lIA0KPiA+ID4gd2hlbiBpdCBlbmNvdW50ZXJzIFRMQiBtaXNzIGFuZCB0aGUgYXV0
b21hdGljIHByZWZldGNoZXIgZG9lc24ndC4NCj4gPiANCj4gPiBXb3csIHRoYW5rcyBmb3IgdGhl
IGxpbmsuDQo+ID4gSSBkaWRuJ3Qga25vdyBhYm91dCB0aGF0IHN1YnRsZSBpc3N1ZSB3aXRoIHBy
ZWZldGNoIGluc3RydWN0aW9ucyBvbiBBUk0gYW5kIHg4Ni4NCj4gPiANCj4gPiBTbyBPSyBpbiBj
YXNlIG9mIFVETCB0aGVzZSBwcmVmZXRjaGVzIGFueXdheXMgbWFrZSBub3Qgbm90IG11Y2ggc2Vu
c2UgSSBndWVzcyBhbmQgdGhlcmUncw0KPiA+IHNvbWV0aGluZyB3b3JzZSBzdGlsbCwgc2VlIHdo
YXQgSSd2ZSBnb3QgZnJvbSBXYW5kQm9hcmQgUXVhZCBydW5uaW5nIGttc2N1YmUgWzFdIGFwcGxp
Y2F0aW9uDQo+ID4gd2l0aCBoZWxwIG9mIHBlcmYgdXRpbGl0eToNCj4gPiAtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0+OC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiAjIE92ZXJoZWFk
ICBDb21tYW5kICBTaGFyZWQgT2JqZWN0ICAgICAgICAgICAgU3ltYm9sIA0KPiA+ICMgLi4uLi4u
Li4gIC4uLi4uLi4gIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uICAuLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uDQo+ID4gIw0KPiA+ICAgICA5Mi45MyUgIGttc2N1YmUgIFtr
ZXJuZWwua2FsbHN5bXNdICAgICAgICBba10gdWRsX3JlbmRlcl9obGluZQ0KPiA+ICAgICAgMi41
MSUgIGttc2N1YmUgIFtrZXJuZWwua2FsbHN5bXNdICAgICAgICBba10gX19kaXZzaTMNCj4gPiAg
ICAgIDAuMzMlICBrbXNjdWJlICBba2VybmVsLmthbGxzeW1zXSAgICAgICAgW2tdIF9yYXdfc3Bp
bl91bmxvY2tfaXJxcmVzdG9yZQ0KPiA+ICAgICAgMC4yMiUgIGttc2N1YmUgIFtrZXJuZWwua2Fs
bHN5bXNdICAgICAgICBba10gbG9ja19hY3F1aXJlDQo+ID4gICAgICAwLjE5JSAga21zY3ViZSAg
W2tlcm5lbC5rYWxsc3ltc10gICAgICAgIFtrXSBfcmF3X3NwaW5fdW5sb2NrX2lycQ0KPiA+ICAg
ICAgMC4xNyUgIGttc2N1YmUgIFtrZXJuZWwua2FsbHN5bXNdICAgICAgICBba10gdWRsX2hhbmRs
ZV9kYW1hZ2UNCj4gPiAgICAgIDAuMTIlICBrbXNjdWJlICBba2VybmVsLmthbGxzeW1zXSAgICAg
ICAgW2tdIHY3X2RtYV9jbGVhbl9yYW5nZQ0KPiA+ICAgICAgMC4xMSUgIGttc2N1YmUgIFtrZXJu
ZWwua2FsbHN5bXNdICAgICAgICBba10gbDJjMjEwX2NsZWFuX3JhbmdlDQo+ID4gICAgICAwLjA2
JSAga21zY3ViZSAgW2tlcm5lbC5rYWxsc3ltc10gICAgICAgIFtrXSBfX21lbXplcm8NCj4gPiAt
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+OC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g
PiANCj4gPiBUaGF0IHNhaWQgaXQncyBub3QgZXZlbiBVU0IgMi4wIHdoaWNoIGlzIGEgYm90dGxl
LW5lY2sgYnV0DQo+ID4gY29tcHV0YXRpb25zIGluIHRoZSB1ZGxfcmVuZGVyX2hsaW5lKCkuDQo+
ID4gDQo+ID4gDQo+ID4gWzFdIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91
cmw/dT1odHRwcy0zQV9fY2dpdC5mcmVlZGVza3RvcC5vcmdfbWVzYV9rbXNjdWJlXyZkPUR3SUJB
ZyZjPURQTDZfWF82SmtYRng3QVhXcUIwdGcmcj1scWRlZVNTRWVzMEdGRERsNjUNCj4gPiA2ZVZp
WE83YnJlUzU1eXRXa2hwazVSODFJJm09cGo2MC0yYUxRZWVQdXpLX2xvMGxRMWo5R2Vud1Nualo2
VW1JM3JfbmJCVSZzPUpNVWszX1lkT3BFUVRiSXlBczBoR3ZiVWdOUmhuNHl0bElhSjlpRV9MYmsm
ZT0NCj4gPiANCj4gPiAtQWxleGV5DQo+IA0KPiBUcnkgdGhpcyBwYXRjaCANCj4gaHR0cHM6Ly91
cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3Blb3BsZS5yZWRoYXQu
Y29tXy03RW1wYXRvY2thX3BhdGNoZXNfa2VybmVsX3VkbF91ZGxrbXMtMkRhdm9pZC0yRGRpdmlz
aW9uLnBhdGNoJmQ9RHdJQkFnJmM9RFBMNg0KPiBfWF82SmtYRng3QVhXcUIwdGcmcj1scWRlZVNT
RWVzMEdGRERsNjU2ZVZpWE83YnJlUzU1eXRXa2hwazVSODFJJm09cGo2MC0NCj4gMmFMUWVlUHV6
S19sbzBsUTFqOUdlbndTbmpaNlVtSTNyX25iQlUmcz1ITkptQWFEaDJ1bzl3dFlzQ2h3dV9UcGVP
WTVQbWtVRHBpY0ZBcnpLM3dFJmU9DQo+IA0KPiBJdCBpcyBkb2luZyBhIGxvdCBvZiBkaXZpc2lv
bnMgLSBhbmQgV2FuZEJvYXJkIGhhcyBDb3J0ZXgtQTksIHRoYXQgZG9lc24ndCANCj4gaGF2ZSBk
aXZpc2lvbiBpbnN0cnVjdGlvbi4NCg0KTG9va3MgbGlrZSB0aGF0IHBhdGNoIG1ha2VzIG5vdCB0
aGF0IG11Y2ggb2YgYSBkaWZmZXJlbmNlLg0KDQpCZWxvdyBhcmUgcmVzdWx0cyBvZiBwZXJmLg0K
DQpXaXRob3V0IHBhdGNoOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+OC0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiA5MS40NiUga21zY3ViZSAgW2tl
cm5lbC5rYWxsc3ltc10gICAgICAgIFtrXSB1ZGxfcmVuZGVyX2hsaW5lDQogMi4xNSUgIGttc2N1
YmUgIFtrZXJuZWwua2FsbHN5bXNdICAgICAgICBba10gX19kaXZzaTMNCiAxLjA5JSAga21zY3Vi
ZSAgW2tlcm5lbC5rYWxsc3ltc10gICAgICAgIFtrXSBtbWlvc2V0DQogMC40OCUgIGttc2N1YmUg
IFtrZXJuZWwua2FsbHN5bXNdICAgICAgICBba10gX3Jhd19zcGluX3VubG9ja19pcnENCiAwLjQ4
JSAga21zY3ViZSAgW2tlcm5lbC5rYWxsc3ltc10gICAgICAgIFtrXSB2N19kbWFfY2xlYW5fcmFu
Z2UNCiAwLjM0JSAga21zY3ViZSAgW2tlcm5lbC5rYWxsc3ltc10gICAgICAgIFtrXSBfcmF3X3Nw
aW5fdW5sb2NrX2lycXJlc3RvcmUNCiAwLjI4JSAga21zY3ViZSAgW2tlcm5lbC5rYWxsc3ltc10g
ICAgICAgIFtrXSBsMmMyMTBfY2xlYW5fcmFuZ2UNCiAwLjI1JSAga21zY3ViZSAgW2tlcm5lbC5r
YWxsc3ltc10gICAgICAgIFtrXSBzaG1lbV9nZXRwYWdlX2dmcC5jb25zdHByb3AuNA0KIDAuMTgl
ICBrbXNjdWJlICBba2VybmVsLmthbGxzeW1zXSAgICAgICAgW2tdIGxvY2tfYWNxdWlyZQ0KDQpX
aXRoIHBhdGNoOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+OC0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiA5NC44MSUga21zY3ViZSAgW2tlcm5lbC5r
YWxsc3ltc10gICAgICAgIFtrXSB1ZGxfcmVuZGVyX2hsaW5lDQogMC44OCUgIGttc2N1YmUgIFtr
ZXJuZWwua2FsbHN5bXNdICAgICAgICBba10gbW1pb3NldA0KIDAuNDQlICBrbXNjdWJlICBba2Vy
bmVsLmthbGxzeW1zXSAgICAgICAgW2tdIF9yYXdfc3Bpbl91bmxvY2tfaXJxDQogMC4zOCUgIGtt
c2N1YmUgIFtrZXJuZWwua2FsbHN5bXNdICAgICAgICBba10gdjdfZG1hX2NsZWFuX3JhbmdlDQog
MC4zMyUgIGttc2N1YmUgIFtrZXJuZWwua2FsbHN5bXNdICAgICAgICBba10gX3Jhd19zcGluX3Vu
bG9ja19pcnFyZXN0b3JlDQogMC4yMiUgIGttc2N1YmUgIFtrZXJuZWwua2FsbHN5bXNdICAgICAg
ICBba10gbDJjMjEwX2NsZWFuX3JhbmdlDQogMC4xNiUgIGttc2N1YmUgIFtrZXJuZWwua2FsbHN5
bXNdICAgICAgICBba10gc2htZW1fZ2V0cGFnZV9nZnAuY29uc3Rwcm9wLjQNCiAwLjE2JSAga21z
Y3ViZSAgW2tlcm5lbC5rYWxsc3ltc10gICAgICAgIFtrXSB1ZGxfaGFuZGxlX2RhbWFnZQ0KIDAu
MTYlICBrbXNjdWJlICBba2VybmVsLmthbGxzeW1zXSAgICAgICAgW2tdIGxvY2tfYWNxdWlyZQ0K
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+OC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhlcmUgaXMgbm8gbW9kZSBfX2RpdnNpMyBmdW5jdGlvbiBp
biBwZXJmIHJlc3VsdHMsIHNvIHBhdGNoIHdvcmtzLg0KQnV0IHRoaXMgZnVuY3Rpb24gd2FzIGp1
c3QgfjIlIG9mIG92ZXJhbGwgb3ZlcmhlYWQuDQoNCi1BbGV4ZXk
WARNING: multiple messages have this Message-ID (diff)
From: Alexey.Brodkin@synopsys.com (Alexey Brodkin)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH 08/21] udl-kms: avoid prefetch
Date: Fri, 15 Jun 2018 16:30:01 +0000 [thread overview]
Message-ID: <c00416da8a1fd5bb3678b5eb6148fcc631848367.camel@synopsys.com> (raw)
In-Reply-To: <alpine.LRH.2.02.1806061138080.7464@file01.intranet.prod.int.rdu2.redhat.com>
Hi Mikulas,
On Wed, 2018-06-06@11:46 -0400, Mikulas Patocka wrote:
>
> On Wed, 6 Jun 2018, Alexey Brodkin wrote:
>
> > Hi Mikulas,
> >
> > On Tue, 2018-06-05@11:30 -0400, Mikulas Patocka wrote:
> > >
> > > On Tue, 5 Jun 2018, Alexey Brodkin wrote:
> > >
> > > > Hi Mikulas,
> > > >
> > > > On Sun, 2018-06-03@16:41 +0200, Mikulas Patocka wrote:
> > > > > Modern processors can detect linear memory accesses and prefetch data
> > > > > automatically, so there's no need to use prefetch.
> > > >
> > > > Not each and every CPU that's capable of running Linux has prefetch
> > > > functionality :)
> > > >
> > > > Still read-on...
> > > >
> > > > > Signed-off-by: Mikulas Patocka <mpatocka at redhat.com>
> > > > >
> > > > > ---
> > > > > drivers/gpu/drm/udl/udl_transfer.c | 7 -------
> > > > > 1 file changed, 7 deletions(-)
> > > > >
> > > > > Index: linux-4.16.12/drivers/gpu/drm/udl/udl_transfer.c
> > > > > ===================================================================
> > > > > --- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_transfer.c 2018-05-31 14:48:12.000000000 +0200
> > > > > +++ linux-4.16.12/drivers/gpu/drm/udl/udl_transfer.c 2018-05-31 14:48:12.000000000 +0200
> > > > > @@ -13,7 +13,6 @@
> > > > > #include <linux/module.h>
> > > > > #include <linux/slab.h>
> > > > > #include <linux/fb.h>
> > > > > -#include <linux/prefetch.h>
> > > > > #include <asm/unaligned.h>
> > > > >
> > > > > #include <drm/drmP.h>
> > > > > @@ -51,9 +50,6 @@ static int udl_trim_hline(const u8 *bbac
> > > > > int start = width;
> > > > > int end = width;
> > > > >
> > > > > - prefetch((void *) front);
> > > > > - prefetch((void *) back);
> > > >
> > > > AFAIK prefetcher fetches new data according to a known history... i.e. based on previously
> > > > used pattern we'll trying to get the next batch of data.
> > > >
> > > > But the code above is in the very beginning of the data processing routine where
> > > > prefetcher doesn't yet have any history to know what and where to prefetch.
> > > >
> > > > So I'd say this particular usage is good.
> > > > At least those prefetches shouldn't hurt because typically it
> > > > would be just 1 instruction if those exist or nothing if CPU/compiler doesn't
> > > > support it.
> > >
> > > See this post https://urldefense.proofpoint.com/v2/url?u=https-3A__lwn.net_Articles_444336_&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl
> > > 656e
> > > ViXO7breS55ytWkhpk5R81I&m=a5RaqJtvajFkM1hL7bOKD5jV7cpFfTvG2Y1cYCdBPd0&s=w0W8wFtAgENp8TE6RzdPGhdKRasJc_otIn08V0EkgrY&e= where they measured that
> > > prefetch hurts performance. Prefetch shouldn't be used unless you have a
> > > proof that it improves performance.
> > >
> > > The problem is that the prefetch instruction causes stalls in the pipeline
> > > when it encounters TLB miss and the automatic prefetcher doesn't.
> >
> > Wow, thanks for the link.
> > I didn't know about that subtle issue with prefetch instructions on ARM and x86.
> >
> > So OK in case of UDL these prefetches anyways make not not much sense I guess and there's
> > something worse still, see what I've got from WandBoard Quad running kmscube [1] application
> > with help of perf utility:
> > --------------------------->8-------------------------
> > # Overhead Command Shared Object Symbol
> > # ........ ....... ....................... ........................................
> > #
> > 92.93% kmscube [kernel.kallsyms] [k] udl_render_hline
> > 2.51% kmscube [kernel.kallsyms] [k] __divsi3
> > 0.33% kmscube [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
> > 0.22% kmscube [kernel.kallsyms] [k] lock_acquire
> > 0.19% kmscube [kernel.kallsyms] [k] _raw_spin_unlock_irq
> > 0.17% kmscube [kernel.kallsyms] [k] udl_handle_damage
> > 0.12% kmscube [kernel.kallsyms] [k] v7_dma_clean_range
> > 0.11% kmscube [kernel.kallsyms] [k] l2c210_clean_range
> > 0.06% kmscube [kernel.kallsyms] [k] __memzero
> > --------------------------->8-------------------------
> >
> > That said it's not even USB 2.0 which is a bottle-neck but
> > computations in the udl_render_hline().
> >
> >
> > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__cgit.freedesktop.org_mesa_kmscube_&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl65
> > 6eViXO7breS55ytWkhpk5R81I&m=pj60-2aLQeePuzK_lo0lQ1j9GenwSnjZ6UmI3r_nbBU&s=JMUk3_YdOpEQTbIyAs0hGvbUgNRhn4ytlIaJ9iE_Lbk&e=
> >
> > -Alexey
>
> Try this patch
> https://urldefense.proofpoint.com/v2/url?u=http-3A__people.redhat.com_-7Empatocka_patches_kernel_udl_udlkms-2Davoid-2Ddivision.patch&d=DwIBAg&c=DPL6
> _X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=pj60-
> 2aLQeePuzK_lo0lQ1j9GenwSnjZ6UmI3r_nbBU&s=HNJmAaDh2uo9wtYsChwu_TpeOY5PmkUDpicFArzK3wE&e=
>
> It is doing a lot of divisions - and WandBoard has Cortex-A9, that doesn't
> have division instruction.
Looks like that patch makes not that much of a difference.
Below are results of perf.
Without patch:
----------------------------->8-------------------------------------------
91.46% kmscube [kernel.kallsyms] [k] udl_render_hline
2.15% kmscube [kernel.kallsyms] [k] __divsi3
1.09% kmscube [kernel.kallsyms] [k] mmioset
0.48% kmscube [kernel.kallsyms] [k] _raw_spin_unlock_irq
0.48% kmscube [kernel.kallsyms] [k] v7_dma_clean_range
0.34% kmscube [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
0.28% kmscube [kernel.kallsyms] [k] l2c210_clean_range
0.25% kmscube [kernel.kallsyms] [k] shmem_getpage_gfp.constprop.4
0.18% kmscube [kernel.kallsyms] [k] lock_acquire
With patch:
----------------------------->8-------------------------------------------
94.81% kmscube [kernel.kallsyms] [k] udl_render_hline
0.88% kmscube [kernel.kallsyms] [k] mmioset
0.44% kmscube [kernel.kallsyms] [k] _raw_spin_unlock_irq
0.38% kmscube [kernel.kallsyms] [k] v7_dma_clean_range
0.33% kmscube [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
0.22% kmscube [kernel.kallsyms] [k] l2c210_clean_range
0.16% kmscube [kernel.kallsyms] [k] shmem_getpage_gfp.constprop.4
0.16% kmscube [kernel.kallsyms] [k] udl_handle_damage
0.16% kmscube [kernel.kallsyms] [k] lock_acquire
----------------------------->8-------------------------------------------
There is no mode __divsi3 function in perf results, so patch works.
But this function was just ~2% of overall overhead.
-Alexey
WARNING: multiple messages have this Message-ID (diff)
From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
To: "mpatocka@redhat.com" <mpatocka@redhat.com>
Cc: "linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
"ladis@linux-mips.org" <ladis@linux-mips.org>,
"b.zolnierkie@samsung.com" <b.zolnierkie@samsung.com>,
"bernie@plugable.com" <bernie@plugable.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
Evgeniy Didin <Evgeniy.Didin@synopsys.com>,
"airlied@redhat.com" <airlied@redhat.com>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>
Subject: Re: [PATCH 08/21] udl-kms: avoid prefetch
Date: Fri, 15 Jun 2018 16:30:01 +0000 [thread overview]
Message-ID: <c00416da8a1fd5bb3678b5eb6148fcc631848367.camel@synopsys.com> (raw)
In-Reply-To: <alpine.LRH.2.02.1806061138080.7464@file01.intranet.prod.int.rdu2.redhat.com>
Hi Mikulas,
On Wed, 2018-06-06 at 11:46 -0400, Mikulas Patocka wrote:
>
> On Wed, 6 Jun 2018, Alexey Brodkin wrote:
>
> > Hi Mikulas,
> >
> > On Tue, 2018-06-05 at 11:30 -0400, Mikulas Patocka wrote:
> > >
> > > On Tue, 5 Jun 2018, Alexey Brodkin wrote:
> > >
> > > > Hi Mikulas,
> > > >
> > > > On Sun, 2018-06-03 at 16:41 +0200, Mikulas Patocka wrote:
> > > > > Modern processors can detect linear memory accesses and prefetch data
> > > > > automatically, so there's no need to use prefetch.
> > > >
> > > > Not each and every CPU that's capable of running Linux has prefetch
> > > > functionality :)
> > > >
> > > > Still read-on...
> > > >
> > > > > Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> > > > >
> > > > > ---
> > > > > drivers/gpu/drm/udl/udl_transfer.c | 7 -------
> > > > > 1 file changed, 7 deletions(-)
> > > > >
> > > > > Index: linux-4.16.12/drivers/gpu/drm/udl/udl_transfer.c
> > > > > ===================================================================
> > > > > --- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_transfer.c 2018-05-31 14:48:12.000000000 +0200
> > > > > +++ linux-4.16.12/drivers/gpu/drm/udl/udl_transfer.c 2018-05-31 14:48:12.000000000 +0200
> > > > > @@ -13,7 +13,6 @@
> > > > > #include <linux/module.h>
> > > > > #include <linux/slab.h>
> > > > > #include <linux/fb.h>
> > > > > -#include <linux/prefetch.h>
> > > > > #include <asm/unaligned.h>
> > > > >
> > > > > #include <drm/drmP.h>
> > > > > @@ -51,9 +50,6 @@ static int udl_trim_hline(const u8 *bbac
> > > > > int start = width;
> > > > > int end = width;
> > > > >
> > > > > - prefetch((void *) front);
> > > > > - prefetch((void *) back);
> > > >
> > > > AFAIK prefetcher fetches new data according to a known history... i.e. based on previously
> > > > used pattern we'll trying to get the next batch of data.
> > > >
> > > > But the code above is in the very beginning of the data processing routine where
> > > > prefetcher doesn't yet have any history to know what and where to prefetch.
> > > >
> > > > So I'd say this particular usage is good.
> > > > At least those prefetches shouldn't hurt because typically it
> > > > would be just 1 instruction if those exist or nothing if CPU/compiler doesn't
> > > > support it.
> > >
> > > See this post https://urldefense.proofpoint.com/v2/url?u=https-3A__lwn.net_Articles_444336_&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl
> > > 656e
> > > ViXO7breS55ytWkhpk5R81I&m=a5RaqJtvajFkM1hL7bOKD5jV7cpFfTvG2Y1cYCdBPd0&s=w0W8wFtAgENp8TE6RzdPGhdKRasJc_otIn08V0EkgrY&e= where they measured that
> > > prefetch hurts performance. Prefetch shouldn't be used unless you have a
> > > proof that it improves performance.
> > >
> > > The problem is that the prefetch instruction causes stalls in the pipeline
> > > when it encounters TLB miss and the automatic prefetcher doesn't.
> >
> > Wow, thanks for the link.
> > I didn't know about that subtle issue with prefetch instructions on ARM and x86.
> >
> > So OK in case of UDL these prefetches anyways make not not much sense I guess and there's
> > something worse still, see what I've got from WandBoard Quad running kmscube [1] application
> > with help of perf utility:
> > --------------------------->8-------------------------
> > # Overhead Command Shared Object Symbol
> > # ........ ....... ....................... ........................................
> > #
> > 92.93% kmscube [kernel.kallsyms] [k] udl_render_hline
> > 2.51% kmscube [kernel.kallsyms] [k] __divsi3
> > 0.33% kmscube [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
> > 0.22% kmscube [kernel.kallsyms] [k] lock_acquire
> > 0.19% kmscube [kernel.kallsyms] [k] _raw_spin_unlock_irq
> > 0.17% kmscube [kernel.kallsyms] [k] udl_handle_damage
> > 0.12% kmscube [kernel.kallsyms] [k] v7_dma_clean_range
> > 0.11% kmscube [kernel.kallsyms] [k] l2c210_clean_range
> > 0.06% kmscube [kernel.kallsyms] [k] __memzero
> > --------------------------->8-------------------------
> >
> > That said it's not even USB 2.0 which is a bottle-neck but
> > computations in the udl_render_hline().
> >
> >
> > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__cgit.freedesktop.org_mesa_kmscube_&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl65
> > 6eViXO7breS55ytWkhpk5R81I&m=pj60-2aLQeePuzK_lo0lQ1j9GenwSnjZ6UmI3r_nbBU&s=JMUk3_YdOpEQTbIyAs0hGvbUgNRhn4ytlIaJ9iE_Lbk&e=
> >
> > -Alexey
>
> Try this patch
> https://urldefense.proofpoint.com/v2/url?u=http-3A__people.redhat.com_-7Empatocka_patches_kernel_udl_udlkms-2Davoid-2Ddivision.patch&d=DwIBAg&c=DPL6
> _X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=pj60-
> 2aLQeePuzK_lo0lQ1j9GenwSnjZ6UmI3r_nbBU&s=HNJmAaDh2uo9wtYsChwu_TpeOY5PmkUDpicFArzK3wE&e=
>
> It is doing a lot of divisions - and WandBoard has Cortex-A9, that doesn't
> have division instruction.
Looks like that patch makes not that much of a difference.
Below are results of perf.
Without patch:
----------------------------->8-------------------------------------------
91.46% kmscube [kernel.kallsyms] [k] udl_render_hline
2.15% kmscube [kernel.kallsyms] [k] __divsi3
1.09% kmscube [kernel.kallsyms] [k] mmioset
0.48% kmscube [kernel.kallsyms] [k] _raw_spin_unlock_irq
0.48% kmscube [kernel.kallsyms] [k] v7_dma_clean_range
0.34% kmscube [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
0.28% kmscube [kernel.kallsyms] [k] l2c210_clean_range
0.25% kmscube [kernel.kallsyms] [k] shmem_getpage_gfp.constprop.4
0.18% kmscube [kernel.kallsyms] [k] lock_acquire
With patch:
----------------------------->8-------------------------------------------
94.81% kmscube [kernel.kallsyms] [k] udl_render_hline
0.88% kmscube [kernel.kallsyms] [k] mmioset
0.44% kmscube [kernel.kallsyms] [k] _raw_spin_unlock_irq
0.38% kmscube [kernel.kallsyms] [k] v7_dma_clean_range
0.33% kmscube [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
0.22% kmscube [kernel.kallsyms] [k] l2c210_clean_range
0.16% kmscube [kernel.kallsyms] [k] shmem_getpage_gfp.constprop.4
0.16% kmscube [kernel.kallsyms] [k] udl_handle_damage
0.16% kmscube [kernel.kallsyms] [k] lock_acquire
----------------------------->8-------------------------------------------
There is no mode __divsi3 function in perf results, so patch works.
But this function was just ~2% of overall overhead.
-Alexey
next prev parent reply other threads:[~2018-06-15 16:30 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-03 14:40 [PATCH 00/21] USB DisplayLink patches Mikulas Patocka
2018-06-03 14:40 ` Mikulas Patocka
2018-06-03 14:40 ` [PATCH 01/21] udl-kms: fix display corruption of the last line Mikulas Patocka
2018-06-03 14:40 ` Mikulas Patocka
2018-06-03 14:40 ` [PATCH 02/21] udl-kms: change down_interruptible to down Mikulas Patocka
2018-06-03 14:40 ` Mikulas Patocka
2018-06-03 14:40 ` [PATCH 03/21] udl-kms: handle allocation failure Mikulas Patocka
2018-06-03 14:40 ` Mikulas Patocka
2018-06-03 14:40 ` [PATCH 04/21] udl-kms: fix crash due to uninitialized memory Mikulas Patocka
2018-06-03 14:40 ` Mikulas Patocka
2018-06-03 14:40 ` [PATCH 05/21] udl-kms: fix a linked-list corruption when using fbdefio Mikulas Patocka
2018-06-03 14:40 ` Mikulas Patocka
2018-06-03 14:40 ` [PATCH 06/21] udl-kms: make a local copy of fb_ops Mikulas Patocka
2018-06-03 14:40 ` Mikulas Patocka
2018-06-03 14:41 ` [PATCH 07/21] udl-kms: avoid division Mikulas Patocka
2018-06-03 14:41 ` Mikulas Patocka
2018-06-03 14:41 ` [PATCH 08/21] udl-kms: avoid prefetch Mikulas Patocka
2018-06-03 14:41 ` Mikulas Patocka
2018-06-05 10:08 ` Alexey Brodkin
2018-06-05 10:08 ` Alexey Brodkin
2018-06-05 10:48 ` Ladislav Michl
2018-06-05 10:48 ` Ladislav Michl
2018-06-05 15:30 ` Mikulas Patocka
2018-06-05 15:30 ` Mikulas Patocka
2018-06-06 12:04 ` Alexey Brodkin
2018-06-06 12:04 ` Alexey Brodkin
2018-06-06 15:46 ` Mikulas Patocka
2018-06-06 15:46 ` Mikulas Patocka
2018-06-15 16:30 ` Alexey Brodkin [this message]
2018-06-15 16:30 ` Alexey Brodkin
2018-06-15 16:30 ` Alexey Brodkin
2018-06-03 14:41 ` [PATCH 09/21] udl-kms: use spin_lock_irq instead of spin_lock_irqsave Mikulas Patocka
2018-06-03 14:41 ` Mikulas Patocka
2018-06-03 14:41 ` [PATCH 10/21] udl-kms: dont spam the syslog with debug messages Mikulas Patocka
2018-06-03 14:41 ` Mikulas Patocka
2018-06-03 14:41 ` [PATCH 11/21] udlfb: fix semaphore value leak Mikulas Patocka
2018-06-03 14:41 ` Mikulas Patocka
2018-06-03 14:41 ` [PATCH 12/21] udlfb: fix display corruption of the last line Mikulas Patocka
2018-06-03 14:41 ` Mikulas Patocka
2018-06-03 14:41 ` [PATCH 13/21] udlfb: dont switch if we are switching to the same videomode Mikulas Patocka
2018-06-03 14:41 ` Mikulas Patocka
2018-06-03 14:41 ` [PATCH 14/21] udlfb: make a local copy of fb_ops Mikulas Patocka
2018-06-03 14:41 ` Mikulas Patocka
2018-06-03 14:41 ` [PATCH 15/21] udlfb: set optimal write delay Mikulas Patocka
2018-06-03 14:41 ` Mikulas Patocka
2018-06-03 14:41 ` [PATCH 16/21] udlfb: handle allocation failure Mikulas Patocka
2018-06-03 14:41 ` Mikulas Patocka
2018-06-03 14:41 ` [PATCH 17/21] udlfb: set line_length in dlfb_ops_set_par Mikulas Patocka
2018-06-03 14:41 ` Mikulas Patocka
2018-06-03 14:41 ` [PATCH 18/21] udlfb: allow reallocating the framebuffer Mikulas Patocka
2018-06-03 14:41 ` Mikulas Patocka
2018-06-03 19:24 ` kbuild test robot
2018-06-03 19:24 ` kbuild test robot
2018-06-12 16:32 ` Mikulas Patocka
2018-06-12 16:32 ` Mikulas Patocka
2018-07-03 14:58 ` Bartlomiej Zolnierkiewicz
2018-07-03 14:58 ` Bartlomiej Zolnierkiewicz
2018-06-03 14:41 ` [PATCH 19/21] udlfb: optimization - test the backing buffer Mikulas Patocka
2018-06-03 14:41 ` Mikulas Patocka
2018-06-03 14:41 ` [PATCH 20/21] udlfb: avoid prefetch Mikulas Patocka
2018-06-03 14:41 ` Mikulas Patocka
2018-06-03 14:41 ` [PATCH 21/21] udlfb: use spin_lock_irq instead of spin_lock_irqsave Mikulas Patocka
2018-06-03 14:41 ` Mikulas Patocka
2018-06-04 1:25 ` [PATCH 00/21] USB DisplayLink patches Dave Airlie
2018-06-04 1:25 ` Dave Airlie
2018-06-04 14:14 ` Mikulas Patocka
2018-06-04 14:14 ` Mikulas Patocka
2018-07-04 8:04 ` Daniel Vetter
2018-07-04 8:04 ` Daniel Vetter
2018-06-05 9:47 ` Alexey Brodkin
2018-06-05 9:47 ` Alexey Brodkin
2018-06-05 15:34 ` Mikulas Patocka
2018-06-05 15:34 ` Mikulas Patocka
2018-07-25 13:40 ` Bartlomiej Zolnierkiewicz
2018-07-25 13:40 ` Bartlomiej Zolnierkiewicz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c00416da8a1fd5bb3678b5eb6148fcc631848367.camel@synopsys.com \
--to=alexey.brodkin@synopsys.com \
--cc=Evgeniy.Didin@synopsys.com \
--cc=airlied@redhat.com \
--cc=b.zolnierkie@samsung.com \
--cc=bernie@plugable.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ladis@linux-mips.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=mpatocka@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.