Akira Tsukamoto wrote:
>
> > - smaller is faster
>
> It could be said more efficient but faster?
Yes, faster. From a whole-system point of view, which is after
all what we care about.
Cache misses are terribly expensive.
> The code or binary size directly connected to this issue?
>
Sure. Large cache footprints in the kernel require more cache
reloads by the kernel and cause more cache reloads on return
to userspace. Thrashing.
> From my patch, about the speed:
> for PIII/4 CPU -> no change. using the same 2.5.45 copy.
> for old i386 -> more optimal.
> for Athlon -> 2.5.45 does not use unrolled copy for it either.
OK. Please integrate you patch into the current kernel's usercopy.c.
> I am away for a while but I grew up in Japan and just wanted to save
> some rooms for a embedded system like below.
> http://linux.ascii24.com/linux/news/today/2000/05/22/imageview/images461056.jpg.html
> The phisical size(not kernel) is about 5cm*5cm.
> Is your copy function suitable in this case?
Well it won't hurt, but it looks like yours improves on it.
The thing which requires some thought is "should the decision
be made at compile time or runtime". For Athlon vs Intel
and i386 vs others, it should be performed at compile time.
-
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/
This archive was generated by hypermail 2b29 : Thu Nov 07 2002 - 22:00:28 EST
