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>,
"airlied@redhat.com" <airlied@redhat.com>
Subject: Re: [PATCH 08/21] udl-kms: avoid prefetch
Date: Tue, 05 Jun 2018 10:08:02 +0000 [thread overview]
Message-ID: <d07eb94b8b20a7b9f57f341a51cdcdbb91a60175.camel@synopsys.com> (raw)
In-Reply-To: <20180603144221.959741603@twibright.com>
SGkgTWlrdWxhcywNCg0KT24gU3VuLCAyMDE4LTA2LTAzIGF0IDE2OjQxICswMjAwLCBNaWt1bGFz
IFBhdG9ja2Egd3JvdGU6DQo+IE1vZGVybiBwcm9jZXNzb3JzIGNhbiBkZXRlY3QgbGluZWFyIG1l
bW9yeSBhY2Nlc3NlcyBhbmQgcHJlZmV0Y2ggZGF0YQ0KPiBhdXRvbWF0aWNhbGx5LCBzbyB0aGVy
ZSdzIG5vIG5lZWQgdG8gdXNlIHByZWZldGNoLg0KDQpOb3QgZWFjaCBhbmQgZXZlcnkgQ1BVIHRo
YXQncyBjYXBhYmxlIG9mIHJ1bm5pbmcgTGludXggaGFzIHByZWZldGNoDQpmdW5jdGlvbmFsaXR5
IDopDQoNClN0aWxsIHJlYWQtb24uLi4NCg0KPiBTaWduZWQtb2ZmLWJ5OiBNaWt1bGFzIFBhdG9j
a2EgPG1wYXRvY2thQHJlZGhhdC5jb20+DQo+IA0KPiAtLS0NCj4gIGRyaXZlcnMvZ3B1L2RybS91
ZGwvdWRsX3RyYW5zZmVyLmMgfCAgICA3IC0tLS0tLS0NCj4gIDEgZmlsZSBjaGFuZ2VkLCA3IGRl
bGV0aW9ucygtKQ0KPiANCj4gSW5kZXg6IGxpbnV4LTQuMTYuMTIvZHJpdmVycy9ncHUvZHJtL3Vk
bC91ZGxfdHJhbnNmZXIuYw0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+IC0tLSBsaW51eC00LjE2LjEyLm9yaWcv
ZHJpdmVycy9ncHUvZHJtL3VkbC91ZGxfdHJhbnNmZXIuYwkyMDE4LTA1LTMxIDE0OjQ4OjEyLjAw
MDAwMDAwMCArMDIwMA0KPiArKysgbGludXgtNC4xNi4xMi9kcml2ZXJzL2dwdS9kcm0vdWRsL3Vk
bF90cmFuc2Zlci5jCTIwMTgtMDUtMzEgMTQ6NDg6MTIuMDAwMDAwMDAwICswMjAwDQo+IEBAIC0x
Myw3ICsxMyw2IEBADQo+ICAjaW5jbHVkZSA8bGludXgvbW9kdWxlLmg+DQo+ICAjaW5jbHVkZSA8
bGludXgvc2xhYi5oPg0KPiAgI2luY2x1ZGUgPGxpbnV4L2ZiLmg+DQo+IC0jaW5jbHVkZSA8bGlu
dXgvcHJlZmV0Y2guaD4NCj4gICNpbmNsdWRlIDxhc20vdW5hbGlnbmVkLmg+DQo+ICANCj4gICNp
bmNsdWRlIDxkcm0vZHJtUC5oPg0KPiBAQCAtNTEsOSArNTAsNiBAQCBzdGF0aWMgaW50IHVkbF90
cmltX2hsaW5lKGNvbnN0IHU4ICpiYmFjDQo+ICAJaW50IHN0YXJ0ID0gd2lkdGg7DQo+ICAJaW50
IGVuZCA9IHdpZHRoOw0KPiAgDQo+IC0JcHJlZmV0Y2goKHZvaWQgKikgZnJvbnQpOw0KPiAtCXBy
ZWZldGNoKCh2b2lkICopIGJhY2spOw0KDQpBRkFJSyBwcmVmZXRjaGVyIGZldGNoZXMgbmV3IGRh
dGEgYWNjb3JkaW5nIHRvIGEga25vd24gaGlzdG9yeS4uLiBpLmUuIGJhc2VkIG9uIHByZXZpb3Vz
bHkNCnVzZWQgcGF0dGVybiB3ZSdsbCB0cnlpbmcgdG8gZ2V0IHRoZSBuZXh0IGJhdGNoIG9mIGRh
dGEuDQoNCkJ1dCB0aGUgY29kZSBhYm92ZSBpcyBpbiB0aGUgdmVyeSBiZWdpbm5pbmcgb2YgdGhl
IGRhdGEgcHJvY2Vzc2luZyByb3V0aW5lIHdoZXJlDQpwcmVmZXRjaGVyIGRvZXNuJ3QgeWV0IGhh
dmUgYW55IGhpc3RvcnkgdG8ga25vdyB3aGF0IGFuZCB3aGVyZSB0byBwcmVmZXRjaC4NCg0KU28g
SSdkIHNheSB0aGlzIHBhcnRpY3VsYXIgdXNhZ2UgaXMgZ29vZC4NCkF0IGxlYXN0IHRob3NlIHBy
ZWZldGNoZXMgc2hvdWxkbid0IGh1cnQgYmVjYXVzZSB0eXBpY2FsbHkgaXQNCndvdWxkIGJlIGp1
c3QgMSBpbnN0cnVjdGlvbiBpZiB0aG9zZSBleGlzdCBvciBub3RoaW5nIGlmIENQVS9jb21waWxl
ciBkb2Vzbid0DQpzdXBwb3J0IGl0Lg0KDQo+ICAJZm9yIChqID0gMDsgaiA8IHdpZHRoOyBqKysp
IHsNCj4gIAkJaWYgKGJhY2tbal0gIT0gZnJvbnRbal0pIHsNCj4gIAkJCXN0YXJ0ID0gajsNCj4g
QEAgLTE0MCw4ICsxMzYsNiBAQCBzdGF0aWMgdm9pZCB1ZGxfY29tcHJlc3NfaGxpbmUxNigNCj4g
IAkJY29uc3QgdTggKmNtZF9waXhlbF9zdGFydCwgKmNtZF9waXhlbF9lbmQgPSBOVUxMOw0KPiAg
CQl1aW50MTZfdCBwaXhlbF92YWwxNjsNCj4gIA0KPiAtCQlwcmVmZXRjaHcoKHZvaWQgKikgY21k
KTsgLyogcHVsbCBpbiBvbmUgY2FjaGUgbGluZSBhdCBsZWFzdCAqLw0KPiAtDQoNClByZXR0eSBt
dWNoIHRoZSBzYW1lIGlzIGhlcmUuIE9idmlvdXNseSBvbiB0aGUgZmlyc3QgaXRlcmF0aW9uIHBy
ZWZldGNoZXIgZG9zbid0DQprbm93IHdoZXJlIHRvIGdldCAiY21kIi4gT24gdGhlIG5leHQgaXRl
cmF0aW9ucyBpdCBtaWdodCBiZSBiZXR0ZXIgYnV0IGdpdmVuIGFtb3VudA0Kb2Ygb3BlcmF0aW9u
IGhhcHBlbnMgZnVydGhlciBpbiB0aGUgY3ljbGUgKGFuZCBpbiBpbm5lciBjeWNsZXMpIEkgd29u
J3QgYmUgY29tcGxldGVseQ0Kc3VyZSB0aGF0IGVhY2ggYW5kIGV2ZXJ5IHByZWZldGNoZXIgd2ls
bCBzdGlsbCBrZWVwIHRyYWNrIG9mICJjbWQiLg0KDQo+ICAJCSpjbWQrKyA9IDB4YWY7DQo+ICAJ
CSpjbWQrKyA9IDB4NmI7DQo+ICAJCSpjbWQrKyA9ICh1aW50OF90KSAoKGRldl9hZGRyID4+IDE2
KSAmIDB4RkYpOw0KPiBAQCAtMTU4LDcgKzE1Miw2IEBAIHN0YXRpYyB2b2lkIHVkbF9jb21wcmVz
c19obGluZTE2KA0KPiAgCQkJCQkodW5zaWduZWQgbG9uZykocGl4ZWxfZW5kIC0gcGl4ZWwpID4+
IGxvZ19icHAsDQo+ICAJCQkJCSh1bnNpZ25lZCBsb25nKShjbWRfYnVmZmVyX2VuZCAtIDEgLSBj
bWQpIC8gMikgPDwgbG9nX2JwcCk7DQo+ICANCj4gLQkJcHJlZmV0Y2hfcmFuZ2UoKHZvaWQgKikg
cGl4ZWwsIGNtZF9waXhlbF9lbmQgLSBwaXhlbCk7DQoNCkFnYWluIEknbSBub3Qgc3VyZSB3aGF0
IHdlIGdhaW4gcmVtb3ZpbmcgdGhhdCBjb2RlIGluIGNvbXBhcmlzb24gb2YgcG9zc2libGUNCnBl
cmZvcm1hbmNlIGRlZ3JhZGF0aW9uIG9uIHNpbXBsZXIgQ1BVcy4NCg0KQW5kIGVzc2VudGlhbGx5
IGFsbCB0aGUgc2FtZSBpcyBhcHBsaWNhYmxlIHRvIFVETEZCIHBhdGNoLg0KDQotQWxleGV5
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>,
"airlied@redhat.com" <airlied@redhat.com>
Subject: Re: [PATCH 08/21] udl-kms: avoid prefetch
Date: Tue, 5 Jun 2018 10:08:02 +0000 [thread overview]
Message-ID: <d07eb94b8b20a7b9f57f341a51cdcdbb91a60175.camel@synopsys.com> (raw)
In-Reply-To: <20180603144221.959741603@twibright.com>
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.
> for (j = 0; j < width; j++) {
> if (back[j] != front[j]) {
> start = j;
> @@ -140,8 +136,6 @@ static void udl_compress_hline16(
> const u8 *cmd_pixel_start, *cmd_pixel_end = NULL;
> uint16_t pixel_val16;
>
> - prefetchw((void *) cmd); /* pull in one cache line at least */
> -
Pretty much the same is here. Obviously on the first iteration prefetcher dosn't
know where to get "cmd". On the next iterations it might be better but given amount
of operation happens further in the cycle (and in inner cycles) I won't be completely
sure that each and every prefetcher will still keep track of "cmd".
> *cmd++ = 0xaf;
> *cmd++ = 0x6b;
> *cmd++ = (uint8_t) ((dev_addr >> 16) & 0xFF);
> @@ -158,7 +152,6 @@ static void udl_compress_hline16(
> (unsigned long)(pixel_end - pixel) >> log_bpp,
> (unsigned long)(cmd_buffer_end - 1 - cmd) / 2) << log_bpp);
>
> - prefetch_range((void *) pixel, cmd_pixel_end - pixel);
Again I'm not sure what we gain removing that code in comparison of possible
performance degradation on simpler CPUs.
And essentially all the same is applicable to UDLFB patch.
-Alexey
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-06-05 10:08 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 [this message]
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
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=d07eb94b8b20a7b9f57f341a51cdcdbb91a60175.camel@synopsys.com \
--to=alexey.brodkin@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=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.