Can you do some performance measurements with this patch instead? I have
a theory. I bet because we didn't have the linux version of string.h we
are using the glibc version instead which is slower. In fact I bet it will
be faster than byte by byte copy. Give it a try.
--- /usr/src/linus-2.6/drivers/video/fbmem.c 2005-07-28 10:24:11.000000000 -0700
+++ fbmem.c 2005-07-29 12:53:30.000000000 -0700
@@ -15,6 +15,7 @@
#include <linux/module.h>
#include <linux/types.h>
+#include <linux/string.h>
#include <linux/errno.h>
#include <linux/sched.h>
#include <linux/smp_lock.h>
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click