From: Geert Uytterhoeven <geert@linux-m68k.org> To: Doug Anderson <dianders@chromium.org> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>, dri-devel <dri-devel@lists.freedesktop.org>, Linux-Renesas <linux-renesas-soc@vger.kernel.org>, Andrzej Hajda <a.hajda@samsung.com>, Neil Armstrong <narmstrong@baylibre.com>, Jonas Karlman <jonas@kwiboo.se>, Jernej Skrabec <jernej.skrabec@siol.net>, Stephen Boyd <swboyd@chromium.org> Subject: Re: [RFC PATCH 04/11] drm/bridge: ti-sn65dsi86: Use bitmask to store valid rates Date: Wed, 24 Mar 2021 09:47:05 +0100 [thread overview] Message-ID: <CAMuHMdXarCH4rP56HA5hxZ5heyotMD+_KraHu5r35baOe=MHug@mail.gmail.com> (raw) In-Reply-To: <CAD=FV=UDd9LC-sMEk0hn10roeM+Cz6VNekcZomkQXLhfw0-4wA@mail.gmail.com> Hi Doug, On Tue, Mar 23, 2021 at 10:10 PM Doug Anderson <dianders@chromium.org> wrote: > On Sun, Mar 21, 2021 at 8:02 PM Laurent Pinchart > <laurent.pinchart+renesas@ideasonboard.com> wrote: > > > > The valid rates are stored in an array of 8 booleans. Replace it with a > > bitmask to save space. > > I'm curious: do you have evidence that this does anything useful? I > guess you're expecting it to save .text space, right? Stack usage and > execution time differences should be irrelevant--it's not in a > critical section and the difference should be tiny anyway. As far as > .text segment goes, it's not obvious to me that the compiler will use > fewer instructions to manipulate bits compared to booleans. > > Doing a super simple "ls -ah" on vmlinux (unstripped): > > Before: 224820232 bytes > After: 224820376 bytes > > ...so your change made it _bigger_. OK, so running "strip > --strip-debug" on those: > > Before: 26599464 bytes > After: 26599464 bytes I've been surprised by the counter-intuitive impact of similar changes before, too. The result may also differ a lot between arm32 or arm64. > ...so exactly the same. I tried finding some evidence using "readelf -ah": > > Before: > [ 2] .text PROGBITS ffffffc010010000 00020000 > 0000000000b03508 0000000000000000 WAX 0 0 65536 > [ 3] .rodata PROGBITS ffffffc010b20000 00b30000 > 00000000002e84b3 0000000000000000 WAMS 0 0 4096 > > After: > [ 2] .text PROGBITS ffffffc010010000 00020000 > 0000000000b03508 0000000000000000 WAX 0 0 65536 > [ 3] .rodata PROGBITS ffffffc010b20000 00b30000 > 00000000002e84b3 0000000000000000 WAMS 0 0 4096 > > Maybe you have some evidence showing an improvement? Ah, OK. I > disassembled ti_sn_bridge_enable() and your patch saves 12 bytes, but > I guess maybe alignment washes it out in reality... Yes, arm64 is bad w.r.t. this. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org> To: Doug Anderson <dianders@chromium.org> Cc: Jernej Skrabec <jernej.skrabec@siol.net>, Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>, Jonas Karlman <jonas@kwiboo.se>, Neil Armstrong <narmstrong@baylibre.com>, dri-devel <dri-devel@lists.freedesktop.org>, Stephen Boyd <swboyd@chromium.org>, Linux-Renesas <linux-renesas-soc@vger.kernel.org>, Andrzej Hajda <a.hajda@samsung.com> Subject: Re: [RFC PATCH 04/11] drm/bridge: ti-sn65dsi86: Use bitmask to store valid rates Date: Wed, 24 Mar 2021 09:47:05 +0100 [thread overview] Message-ID: <CAMuHMdXarCH4rP56HA5hxZ5heyotMD+_KraHu5r35baOe=MHug@mail.gmail.com> (raw) In-Reply-To: <CAD=FV=UDd9LC-sMEk0hn10roeM+Cz6VNekcZomkQXLhfw0-4wA@mail.gmail.com> Hi Doug, On Tue, Mar 23, 2021 at 10:10 PM Doug Anderson <dianders@chromium.org> wrote: > On Sun, Mar 21, 2021 at 8:02 PM Laurent Pinchart > <laurent.pinchart+renesas@ideasonboard.com> wrote: > > > > The valid rates are stored in an array of 8 booleans. Replace it with a > > bitmask to save space. > > I'm curious: do you have evidence that this does anything useful? I > guess you're expecting it to save .text space, right? Stack usage and > execution time differences should be irrelevant--it's not in a > critical section and the difference should be tiny anyway. As far as > .text segment goes, it's not obvious to me that the compiler will use > fewer instructions to manipulate bits compared to booleans. > > Doing a super simple "ls -ah" on vmlinux (unstripped): > > Before: 224820232 bytes > After: 224820376 bytes > > ...so your change made it _bigger_. OK, so running "strip > --strip-debug" on those: > > Before: 26599464 bytes > After: 26599464 bytes I've been surprised by the counter-intuitive impact of similar changes before, too. The result may also differ a lot between arm32 or arm64. > ...so exactly the same. I tried finding some evidence using "readelf -ah": > > Before: > [ 2] .text PROGBITS ffffffc010010000 00020000 > 0000000000b03508 0000000000000000 WAX 0 0 65536 > [ 3] .rodata PROGBITS ffffffc010b20000 00b30000 > 00000000002e84b3 0000000000000000 WAMS 0 0 4096 > > After: > [ 2] .text PROGBITS ffffffc010010000 00020000 > 0000000000b03508 0000000000000000 WAX 0 0 65536 > [ 3] .rodata PROGBITS ffffffc010b20000 00b30000 > 00000000002e84b3 0000000000000000 WAMS 0 0 4096 > > Maybe you have some evidence showing an improvement? Ah, OK. I > disassembled ti_sn_bridge_enable() and your patch saves 12 bytes, but > I guess maybe alignment washes it out in reality... Yes, arm64 is bad w.r.t. this. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2021-03-24 8:48 UTC|newest] Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-22 3:01 [RFC PATCH 00/11] drm/bridge: ti-sn65dsi86: Support DisplayPort mode Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-22 3:01 ` [RFC PATCH 01/11] dt-bindings: drm/bridge: ti-sn65dsi8: Make enable GPIO optional Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-22 10:29 ` Jagan Teki 2021-03-22 10:29 ` Jagan Teki 2021-03-23 7:10 ` Stephen Boyd 2021-03-23 7:10 ` Stephen Boyd 2021-03-23 21:08 ` Doug Anderson 2021-03-23 21:08 ` Doug Anderson 2021-03-27 16:42 ` Rob Herring 2021-03-27 16:42 ` Rob Herring 2021-03-22 3:01 ` [RFC PATCH 02/11] drm/bridge: ti-sn65dsi86: " Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-22 10:29 ` Jagan Teki 2021-03-22 10:29 ` Jagan Teki 2021-03-23 7:10 ` Stephen Boyd 2021-03-23 7:10 ` Stephen Boyd 2021-03-23 21:08 ` Doug Anderson 2021-03-23 21:08 ` Doug Anderson 2021-03-22 3:01 ` [RFC PATCH 03/11] drm/bridge: ti-sn65dsi86: Unregister AUX adapter in remove() Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-23 7:10 ` Stephen Boyd 2021-03-23 7:10 ` Stephen Boyd 2021-03-23 21:08 ` Doug Anderson 2021-03-23 21:08 ` Doug Anderson 2021-03-23 21:41 ` Laurent Pinchart 2021-03-23 21:41 ` Laurent Pinchart 2021-03-23 22:55 ` Doug Anderson 2021-03-23 22:55 ` Doug Anderson 2021-03-23 23:02 ` Laurent Pinchart 2021-03-23 23:02 ` Laurent Pinchart 2021-03-26 0:43 ` Doug Anderson 2021-03-26 0:43 ` Doug Anderson 2021-03-26 1:01 ` Laurent Pinchart 2021-03-26 1:01 ` Laurent Pinchart 2021-03-22 3:01 ` [RFC PATCH 04/11] drm/bridge: ti-sn65dsi86: Use bitmask to store valid rates Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-23 7:11 ` Stephen Boyd 2021-03-23 7:11 ` Stephen Boyd 2021-03-23 21:08 ` Doug Anderson 2021-03-23 21:08 ` Doug Anderson 2021-03-23 21:45 ` Laurent Pinchart 2021-03-23 21:45 ` Laurent Pinchart 2021-03-23 22:45 ` Doug Anderson 2021-03-23 22:45 ` Doug Anderson 2021-03-24 8:47 ` Geert Uytterhoeven [this message] 2021-03-24 8:47 ` Geert Uytterhoeven 2021-03-22 3:01 ` [RFC PATCH 05/11] drm/bridge: ti-sn65dsi86: Wrap panel with panel-bridge Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-22 10:19 ` Jagan Teki 2021-03-22 10:19 ` Jagan Teki 2021-03-23 7:14 ` Stephen Boyd 2021-03-23 7:14 ` Stephen Boyd 2021-03-23 21:50 ` Laurent Pinchart 2021-03-23 21:50 ` Laurent Pinchart 2021-03-24 22:44 ` Doug Anderson 2021-03-24 22:44 ` Doug Anderson 2021-03-26 1:06 ` Laurent Pinchart 2021-03-26 1:06 ` Laurent Pinchart 2021-03-22 3:01 ` [RFC PATCH 06/11] drm/bridge: ti-sn65dsi86: Group code in sections Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-23 7:14 ` Stephen Boyd 2021-03-23 7:14 ` Stephen Boyd 2021-03-24 22:44 ` Doug Anderson 2021-03-24 22:44 ` Doug Anderson 2021-03-22 3:01 ` [RFC PATCH 07/11] drm/bridge: ti-sn65dsi86: Split connector creation to a function Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-23 7:15 ` Stephen Boyd 2021-03-23 7:15 ` Stephen Boyd 2021-03-24 22:44 ` Doug Anderson 2021-03-24 22:44 ` Doug Anderson 2021-03-22 3:01 ` [RFC PATCH 08/11] drm/bridge: ti-sn65dsi86: Implement bridge connector operations Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-23 7:15 ` Stephen Boyd 2021-03-23 7:15 ` Stephen Boyd 2021-03-24 22:46 ` Doug Anderson 2021-03-24 22:46 ` Doug Anderson 2021-03-26 1:40 ` Laurent Pinchart 2021-03-26 1:40 ` Laurent Pinchart 2021-03-22 3:01 ` [RFC PATCH 09/11] drm/bridge: ti-sn65dsi86: Make connector creation optional Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-22 3:01 ` [RFC PATCH 10/11] drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-24 22:47 ` Doug Anderson 2021-03-24 22:47 ` Doug Anderson 2021-06-23 13:59 ` Laurent Pinchart 2021-06-23 13:59 ` Laurent Pinchart 2022-02-23 18:04 ` Kieran Bingham 2022-02-23 18:04 ` Kieran Bingham 2022-02-23 18:20 ` Doug Anderson 2022-02-23 18:20 ` Doug Anderson 2022-03-04 15:49 ` Laurent Pinchart 2022-03-04 15:49 ` Laurent Pinchart 2021-03-22 3:01 ` [RFC PATCH 11/11] drm/bridge: ti-sn65dsi86: Support hotplug detection Laurent Pinchart 2021-03-22 3:01 ` Laurent Pinchart 2021-03-23 7:21 ` Stephen Boyd 2021-03-23 7:21 ` Stephen Boyd 2021-03-24 22:47 ` Doug Anderson 2021-03-24 22:47 ` Doug Anderson 2021-06-23 23:25 ` Laurent Pinchart 2021-06-23 23:25 ` Laurent Pinchart 2021-06-23 23:51 ` Doug Anderson 2021-06-23 23:51 ` Doug Anderson 2022-02-23 17:43 ` Kieran Bingham 2022-02-23 17:43 ` Kieran Bingham 2022-02-23 18:25 ` Doug Anderson 2022-02-23 18:25 ` Doug Anderson 2022-03-04 15:45 ` Kieran Bingham 2022-03-04 15:45 ` Kieran Bingham 2022-03-04 16:30 ` Doug Anderson 2022-03-04 16:30 ` Doug Anderson
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='CAMuHMdXarCH4rP56HA5hxZ5heyotMD+_KraHu5r35baOe=MHug@mail.gmail.com' \ --to=geert@linux-m68k.org \ --cc=a.hajda@samsung.com \ --cc=dianders@chromium.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=jernej.skrabec@siol.net \ --cc=jonas@kwiboo.se \ --cc=laurent.pinchart+renesas@ideasonboard.com \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=narmstrong@baylibre.com \ --cc=swboyd@chromium.org \ /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: linkBe 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.