> The point is: The code in that "magic page" that considers the
> tradeoff is KERNEL code, which is designed to care about such
> trade-offs for that machine. Glibc never knows this stuff and
> shouldn't, because it is already bloated.

glibc is bloated because it cares about such stuff and complex standards.
There is no reason to make a mess of the kernel when you can handle more
stuff nicely with the libraries.

Since glibc inlines most memcpy calls you'd need to build an MXT glibc,
which is doable. Uninlining most memcpy calls is a loss on some processors
and often a loss anyway as the copies are so small


-
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/

Reply via email to