David Xu wrote:
Mark Kirkwood wrote:
I recently did some testing on the performance of cached reads using
two (almost identical) systems, one running FreeBSD 6.2PRE and the
other running Gentoo Linux - the latter acting as a control. I
initially started a thread of the same name on -stable, but it was
suggested I submit a mail here.
My background for wanting to examine this is that I work with
developing database software (postgres internals related) and cached
read performance is pretty important - since we typically try hard to
encourage cached access whenever possible.
Anyway on to the results: I used the attached program to read a cached
781MB file sequentially and randomly with a specified block size (see
below). The conclusion I came to was that our (i.e FreeBSD) cached
read performance (particularly for smaller block sizes) could perhaps
be improved... now I'm happy to help in any way - the machine I've got
running STABLE can be upgraded to CURRENT in order to try out patches
(or in fact to see if CURRENT is faster at this already!)...
Best wishes
Mark
I suspect in such a test, memory copying speed will be a key factor,
I don't have number to back up my idea, but I think Linux has lots
of tweaks, such as using MMX instruction to copy data.
Regards,
David Xu
David - very interesting - checking 2.6.18 sources I see:
arch/i386/lib/memcpy.c:7->
void *memcpy(void *to, const void *from, size_t n)
{
#ifdef CONFIG_X86_USE_3DNOW
return __memcpy3d(to, from, n);
#else
return __memcpy(to, from, n);
#endif
}
If I understand this correctly, I need CONFIG_X86_USE_3DNOW (or perhaps
CONFIG_M586MMX) set in my Linux kernel config to be using these....
which I don't appear to have (I'll do some more digging and see if maybe
profiling tells us anything useful).
Cheers
Mark
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
