linux-kernel - Re: Big git diff speedup by avoiding x86 "fast string" memcmp

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]

Date:	Wed, 15 Dec 2010 14:57:05 +0900
From:	"J. R. Okajima" <hooanon05@...oo.co.jp>
To:	Nick Piggin <npiggin@...il.com>
Cc:	Nick Piggin <npiggin@...nel.dk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-arch@...r.kernel.org, x86@...nel.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: Big git diff speedup by avoiding x86 "fast string" memcmp


Thank you for explanation.
I understood about padding zero tail bytes as an improvement or a
variation of the 'long *' approach. But I didn't write about it in my
previous mail. If I had written, you might not need to describe again.

I have also compared "repe; cmpsb" and __builtin_memcmp "in userspace".
And __builtin_memcmp shows faster and it looks like an approach of
mixing pointers. Although the code size grows, in source it will be
simple #define and it is already done in x86_32. Do you (or any other
x86 experts) think it is worth to try?


J. R. Okajima

Nick Piggin:
> What I meant is that a "normal" memcmp that does long * memory
> operations is not a good idea, because it requires code and branches
> to handle the tail of the string. When average string lengths are less
> than 16 bytes, it hardly seems wothwhile. It will just get more
> mispredicts and bigger icache footprint.
>
> However instead of a normal memcmp, we could actually pad dentry
> names out to sizeof(long) with zeros, and take advantage of that with
> a memcmp that does not have to handle tails -- it would operate
> entirely with longs.
>
> That would avoid icache and branch regressions, and might speed up
> the operation on some architectures. I just doubted whether it would
> show an improvement to be worth doing at all. If it does, I'm all for it.
--
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/