Re: PATCH 2.3.26: kmalloc GFP_ZEROt

David S. Miller (davem@redhat.com)
Tue, 9 Nov 1999 14:32:37 -0800


Date: Tue, 9 Nov 1999 23:10:51 +0100 (CET)
From: Andrea Arcangeli <andrea@suse.de>

I am against _moving_ the bzero cost in a not obvious
place. Removing it completly also automagically saving data-cache
is a completly different thing and I would like to do that of
course (unfortunately only on machines that have the magic
NCR53c8xx).

Andreas, let me say it for the 1,000th time.

Some cpus in this world allow data cache bypassing to be done during
loads and stores, in fact optimal bcopy/bzero is implemented using
these facilities (especially on chips where the load/store moves an
entire cache line at a time). PPC and Sparc allow this for example.
There is no cache pollution (and with some slick tricks I even avoid
any TLB side-effects during page zero and copy operations on
UltraSparc).

So in these cases, what is this "cost" you keep complaining
about? Yes, perhaps most broken x86 chips don't allow this
to happen (but I bet their microcode can do these sorts of
things if we ever reverse engineered that), but expect more
cpus in the future to provide these sorts of things, not less.

Most L1 data caches are not write-allocate anyways.

Later,
David S. Miller
davem@redhat.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/