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] [day] [month] [year] [list]
Date:	Mon, 12 Dec 2011 10:54:58 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, JBeulich@...e.com,
	tglx@...utronix.de, adobriyan@...il.com, mingo@...e.hu
Cc:	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/asm] x86/i386: Use less assembly in strlen(), speed
 things up a bit

On Mon, Dec 12, 2011 at 10:37 AM, tip-bot for Alexey Dobriyan
<adobriyan@...il.com> wrote:
>
> x86/i386: Use less assembly in strlen(), speed things up a bit

We could probably remove the thing entirely, and just use the generic
strlen. Some of the rep instruction usage is just purely historic,
there's little point.

Using "repne; scasb" is possibly worth it when inlined. And especially
with the change in this patch-set, where inlining also combines with
things like expression simplification, and then things like
"strlen(s)+1" (common for sizing allocations) the compiler can
actually remove the "-1" part entirely. Then the advantage of 'repne
scas' is that it's short.

But for out-of-line, we might actually be better off with just a
traditional loop. Not because we can do multiple bytes in a go (most
kernel strings are likely short enough that it's not a big deal), but
simply because 'repne scas' is not generally all that fast.

I dunno. strlen() usually isn't very hot, so it probably doesn't
matter. The really hot paths tend to do something like computing a
hash at the same time as checking the length of the string or need
something more complex anyway (ie the "hash and find '\0' or '/' in a
pathname" that path walking does). Pure strlen() is reasonably rare.

So it probably doesn't matter. The patch looks like a nice cleanup.

                      Linus
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ