RE: [PATCH 9/9] x86/lib/memset_64.S: Optimize memset by enhancedREP MOVSB/STOSB
From: Yu, Fenghua
Date: Tue May 17 2011 - 23:12:16 EST
> From: Andi Kleen [mailto:andi@xxxxxxxxxxxxxx]
> 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@xxxxxxxxx>
> > Support memset() with enhanced rep stosb. On processors supporting
> > enhanced
> > REP MOVSB/STOSB, the alternative memset_c_e function using enhanced
> > stosb
> > overrides the fast string alternative memset_c and the original
> FWIW most memsets and memcpys are generated by modern gccs as inline
> 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
> 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.
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/