linux-kernel - RE: [PATCH 9/9] x86/lib/memset_64.S: Optimize memset by enhanced REP MOVSB/STOSB

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: <493994B35A117E4F832F97C4719C4C04011505C39D@orsmsx505.amr.corp.intel.com>
Date:	Tue, 17 May 2011 20:09:54 -0700
From:	"Yu, Fenghua" <fenghua.yu@...el.com>
To:	Andi Kleen <andi@...stfloor.org>
CC:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	H Peter Anvin <hpa@...or.com>,
	"Mallick, Asit K" <asit.k.mallick@...el.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Avi Kivity <avi@...hat.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 9/9] x86/lib/memset_64.S: Optimize memset by enhanced
 REP MOVSB/STOSB

> From: Andi Kleen [mailto:andi@...stfloor.org]
> Sent: Tuesday, May 17, 2011 7:58 PM
> To: Yu, Fenghua
> Cc: Ingo Molnar; Thomas Gleixner; H Peter Anvin; Mallick, Asit K; Linus
> Torvalds; Avi Kivity; Arjan van de Ven; Andrew Morton; Andi Kleen;
> linux-kernel; Yu, Fenghua
> Subject: Re: [PATCH 9/9] x86/lib/memset_64.S: Optimize memset by
> enhanced REP MOVSB/STOSB
> 
> > From: Fenghua Yu <fenghua.yu@...el.com>
> >
> > Support memset() with enhanced rep stosb. On processors supporting
> > enhanced
> > REP MOVSB/STOSB, the alternative memset_c_e function using enhanced
> rep
> > stosb
> > overrides the fast string alternative memset_c and the original
> function.
> 
> FWIW most memsets and memcpys are generated by modern gccs as inline
> code,
> depending on alignment etc., so will never call your new function.
> Same may be true for memmove (not fully sure)
> 
> One way to work around this would be to add suitable logic
> to the string.h macros and make sure the out of line code is always
> called for large copies if the count is constant and large enough.
> 
> There used to be such logic, but it was removed partly later.
> 
> The only problem is that it's hard to decide if the count is variable
> and where a good threshold is.
> 
> Or maybe it would be better to just fix gcc to use the new
> instructions,
> but then it would be difficult to patch them in.

Only memcpy are generated by gcc when gcc version >=4.3. Other functions are defined by kernel lib.

I would leave gcc optimization for most memcpy cases instead of forcing memcpy to call the kernel lib memcpy. I hope gcc will catch up and implement a good enhanced rep movsb/stosb solution soon. If turns out gcc can not generate good memcpy, it's easy to switch to the patching kernel lib memcpy.

Thanks.

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