Re: [TRIVIAL] kstrdup

[Jeff Garzik]

Richard B. Johnson wrote:
> On Fri, 18 Apr 2003, Jeff Garzik wrote:
> 
> 
>>Linus Torvalds wrote:
>>
>>>On Fri, 18 Apr 2003, Jeff Garzik wrote:
>>>
>>>
>>>>You should save the strlen result to a temp var, and then s/strcpy/memcpy/
>>>
>>>
>>>No, you should just not do this. I don't see the point.
>>
>>
>>strcpy has a test for each byte of its contents, and memcpy doesn't.
>>Why search 's' for NULL twice?
>>
>>	Jeff
> 
> 
> Because it doesn't. strcpy() is usually implimented by getting
> the string-length, using the same code sequence as strlen(), then
> using the same code sequence as memcpy(), but copying the null-byte
> as well. The check for the null-byte is done in the length routine.
> 
> If you do a memcpy(a, b, strlen(b));, then you are making two
> procedure calls and dirtying the cache twice..

Wrong, because we have to call strlen _anyway_, to provide the size to 
kmalloc.

> A typical Intel procedure, stripped of the push/pops to save
> registers is here....

That's kinda cute.  Why not submit a patch to the strcpy implementation 
in include/asm-i386/string.h?  :)  Ours is shorter, but does have a jump:
         "1:\tlodsb\n\t"
         "stosb\n\t"
         "testb %%al,%%al\n\t"
         "jne 1b"

Which is better?  I don't know; I'm still learning the performance 
eccentricities of x86 insns on various processors.

Related x86 question:  if the memory buffer is not dword-aligned, is 
'rep movsl' the best idea?  On RISC it's usually smarter to unroll the 
head of the loop to avoid unaligned accesses; but from reading x86 asm 
code in the kernel, nobody seems to care about that.  Is the 
unaligned-access penalty so small that the increased code size of the 
head-unroll is never worth it?

> A lot of persons who are unfamiliar with tools other than 'C' think
> that strcpy() is made like this:
> 
> 	while(*dsp++ = *src++)
>                    ;

In fact, that's basically the kernel's non-arch-specific implementation :)

	Jeff