Jeff Garzik writes:
> After a couple of suggestions for improving things, Linus chimed in
> with the magic page suggestion.
Since this is being brought up again, I want to mention something.
If we are going to map in a page like this, there are other cool
things one could do with this page. We should keep it at _1_ page
so people don't go crazy with ideas of stuff to put here btw...
The idea is that the one thing one tends to optimize for new cpus
is the memcpy/memset implementation. What better way to shield
libc from having to be updated for new cpus but to put it into
the kernel in this magic page?
There is a secondary effect to doing this on systems with physically
indexed caches (read as: most if not all x86 cpus today), the kernel's
memcpy/memset call icache usage can be shared with the user.
This also allows things like "kernel disabled cpu feature XYZ because
of a hardware bug, so instead of the usual optimized memcpy for this
processor, memcpy FOO is now faster since the feature is disabled, so
that is what we'll use" Really, libc shouldn't know things like this.
I thought about doing something along these lines on sparc64 sometime
around the next to last Linux EXPO held in North Caroline (the one
which was on the Duke university campus). In fact I believe I
remember specifically mentioning this idea to Jakub Jelinek during
that conference. It's particularly attractive on sparc64 because you
can use a "global" TLB entry which is thus shared between all address
spaces.
Later,
David S. Miller
[EMAIL PROTECTED]
-
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/
