linux-kernel - Re: First kernel patch (optimization)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150916132426.GA7420@kroah.com>
Date:	Wed, 16 Sep 2015 06:24:26 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Austin S Hemmelgarn <ahferroin7@...il.com>
Cc:	Steve Calfee <stevecalfee@...il.com>,
	Eric Curtin <ericcurtin17@...il.com>,
	Valentina Manea <valentina.manea.m@...il.com>,
	shuah.kh@...sung.com, USB list <linux-usb@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: First kernel patch (optimization)

On Wed, Sep 16, 2015 at 07:45:53AM -0400, Austin S Hemmelgarn wrote:
> On 2015-09-15 20:09, Steve Calfee wrote:
> >On Tue, Sep 15, 2015 at 12:53 PM, Eric Curtin <ericcurtin17@...il.com> wrote:
> >>Signed-off-by: Eric Curtin <ericcurtin17@...il.com>
> >>
> >>diff --git a/tools/usb/usbip/src/usbip_detach.c b/tools/usb/usbip/src/usbip_detach.c
> >>index 05c6d15..9db9d21 100644
> >>--- a/tools/usb/usbip/src/usbip_detach.c
> >>+++ b/tools/usb/usbip/src/usbip_detach.c
> >>@@ -47,7 +47,9 @@ static int detach_port(char *port)
> >>         uint8_t portnum;
> >>         char path[PATH_MAX+1];
> >>
> >>-       for (unsigned int i = 0; i < strlen(port); i++)
> >>+       unsigned int port_len = strlen(port);
> >>+
> >>+       for (unsigned int i = 0; i < port_len; i++)
> >>                 if (!isdigit(port[i])) {
> >>                         err("invalid port %s", port);
> >>                         return -1;
> >>
> >>--
> >
> >Hi Eric,
> >
> >This is fine, but what kind of wimpy compiler optimizer will not move
> >the constant initializer out of the loop? I bet if you compare binary
> >sizes/code it will be exactly the same, and you added some characters
> >of code. Reorganizing code for readability is fine, but for compiler
> >(in)efficiency seems like a bad idea.
> While I agree with your argument, I would like to point out that it is a
> well established fact that GCC's optimizers are kind of brain-dead at times
> and need their hands held.
> 
> I'd be willing to bet that the code will be marginally larger (because of
> adding another variable), but might run slightly faster too (because in my
> experience, GCC doesn't always catch things like this), and should compile a
> little faster (because the optimizers don't have to do as much work).

Fun thing is, there's no speed issues with this portion of the code, and
it's in userspace as well, so simplicity is the key that should be
followed here.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/