> > You certainly achieved a giant P5 speedup on bcopies up to 10K,
 > > however, the affect dies out abruptly right there. The P6 issue is with
 > > purely dram writes, whereas your speedup affects only in-cache non-dram
 > > bcopies.
 > 
 > 
 > [ "John F. Woods" <jfw@jfwhome.funhouse.com> ]
 > 
 > Out of curiosity, has this code been benchmarked on 486 processors?  Or
 > 386 processors?  One danger of carefully tuning performance for one
 > member of a processor family is that you end up screwing the other
 > members of the processor family -- and if you make the older and slower
 > machines useless, it is hardly a change that is worthwhile (unless,
 > perhaps, you are an Intel sales rep).  (If it's neutral or beneficial,
 > fine.)
 > 
 > Since it's delicately tuned to caching strategies, I also wonder if
 > there is little enough innovation in motherboard cache design to keep
 > this from being a pessimization for some otherwise-faster P6
 > motherboard design.
 > 
 > > This should definitely be in NetBSD for all those P5 users.
 > 
 > Just make sure the 486 NetBSD users don't decide to roast you over a
 > bonfire.
 > 


Well, *#$&# it.  It's bad news with a write-through cache. (486
primary, most 386 board-level). I dunno how 486 board-level caches are
organized, or even how common they are.  Maybe an #ifdef, or a dynamic
selection?