Re: First kernel patch (optimization)

[Eric Curtin]

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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> wrote:
> > >>Signed-off-by: Eric Curtin <ericcurtin17@xxxxxxxxx>
> > >>
> > >>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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/