lkml.org 
[lkml]   [2011]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: x86 memcpy performance
From
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/

\
 
 \ /
  Last update: 2011-12-05 13:23    [W:0.074 / U:0.968 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site