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: <CANpvso7dcMn2u8of8UDgBdVCx=M6g_VCuqvA8Dt6gkvwPTA6kw@mail.gmail.com>
Date:	Wed, 16 Sep 2015 17:03:39 +0100
From:	Eric Curtin <ericcurtin17@...il.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Austin S Hemmelgarn <ahferroin7@...il.com>,
	Steve Calfee <stevecalfee@...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)

Hi Greg,

As I said in the subject of the mail (which I have been since told I
shouldn't have done this), I'm a noob to kernel code. I tried to pick
off something super simple to just see what the process of getting a
patch in is. Youtube videos and documentation only get you so far.

>From reading your response, should I refrain from sending in these
micro-optimizations in future? Getting in smaller patches is easier
for me as I only do this in my spare time, which I don't have a lot
of!

On 16 September 2015 at 14:24, Greg KH <gregkh@...uxfoundation.org> wrote:
>
> 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/