Messages in this thread | | | Date | Mon, 5 Dec 2011 17:50:49 +0530 | Subject | Re: x86 memcpy performance | From | melwyn lobo <> |
| |
The driver has a loop of memcpy the source and destination addresses based on a runtime computed value and confuses the compiler on the alignement. So instead of generating neat 32 bit memcpy, gcc generates "rep movsb" Example code snippet: src = (char *)kmap(bo->pages[idx]); src += offset; memcpy(des, src, len); Be replacing ssse3 only for memcpy of length larger than 1K bytes (for my driver typical length are 2k metadata from SRAM to DDR) I think overheads of FPU save and restore can be forgiven. Will SSSE3 work for unlaigned pointers as well ? If it doesn't I am lucky for past 6 months :)
On Fri, Sep 9, 2011 at 9:05 PM, Borislav Petkov <bp@alien8.de> wrote: > On Fri, Sep 09, 2011 at 07:39:18AM -0700, Linus Torvalds wrote: >> Kernel memcpy's are basically almost always smaller than a page size, >> because that tends to be the fundamental allocation size. > > Yeah, this is what my trace of a kernel build showed too: > > Bytes Count > ===== ===== > > ... > > 224 3 > 225 3 > 227 3 > 244 1 > 254 5 > 255 13 > 256 21708 > 512 21746 > 848 12907 > 1920 36536 > 2048 21708 > > OTOH, I keep thinking that copy_*_user might be doing bigger sizes, for > example when shuffling network buffers to/from userspace. Converting > those to SSE memcpy might not be as easy as memcpy itself, though. > >> Yes, there are exceptions that copy into big vmalloc'ed buffers, but >> they don't tend to matter. Things like module loading etc. > > Too small a number of repetitions to matter, yes. > > -- > Regards/Gruss, > Boris. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |