[disregard my previous mail. I should have read the whole thread first] On Saturday 02 April 2005 07:50, Robert Hancock wrote: > As it turns out, the memset in my version of glibc x86_64 is not using > such a string instruction though - it seems to be using two different > sets of instructions depending on the size of the memset (not sure > exactly how they're calculating the threshold between these..) For sizes > below the treshold, this is the inner loop - it's using normal mov > instructions: > > 3: /* Copy 64 bytes. */ > mov %r8,(%rcx) > mov %r8,0x8(%rcx) > mov %r8,0x10(%rcx) > mov %r8,0x18(%rcx) > mov %r8,0x20(%rcx) > mov %r8,0x28(%rcx) > mov %r8,0x30(%rcx) > mov %r8,0x38(%rcx) > add $0x40,%rcx > dec %rax > jne 3b > > For sizes above the threshold though, this is the inner loop. It's using > movnti which is an SSE cache-bypasssing store: > > 11: /* Copy 64 bytes without polluting the cache. */ > /* We could use movntdq %xmm0,(%rcx) here to further > speed up for large cases but let's not use XMM registers. */ > movnti %r8,(%rcx) > movnti %r8,0x8(%rcx) > movnti %r8,0x10(%rcx) > movnti %r8,0x18(%rcx) > movnti %r8,0x20(%rcx) > movnti %r8,0x28(%rcx) > movnti %r8,0x30(%rcx) > movnti %r8,0x38(%rcx) > add $0x40,%rcx > dec %rax > jne 11b
This is a very rarely used instruction. People either do plain old rep stosl or do 3DNOW or SSE2 non-temporal stores. Maybe movnti is different (buggy?) in subtle way. Does it blow up if you use 3DNOW or SSE2 non-temporal stores? If yes, then try different BIOS (not nesessarily latest is best). BTW, 'Athlon bug' was tracked down similarly. New BIOS enabled buggy chipset feature - BOOM! non-temporals killed the box (took several months to figure it out back then). -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
