RE: [PATCH 9/9] x86/lib/memset_64.S: Optimize memset by enhancedREP MOVSB/STOSB

[Yu, Fenghua]

> 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
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/