From owner-freebsd-current Sun Mar 18 20:16:47 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 902C737B718; Sun, 18 Mar 2001 20:16:41 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id PAA21125; Mon, 19 Mar 2001 15:16:30 +1100 Date: Mon, 19 Mar 2001 15:16:11 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Dag-Erling Smorgrav Cc: David Malone , current@FreeBSD.ORG, jhb@FreeBSD.ORG, jake@FreeBSD.ORG, Ian Dowse Subject: Re: Interesting backtrace... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 19 Mar 2001, Dag-Erling Smorgrav wrote: > Bruce Evans writes: > > K6-2's aren't really i586's and i586_bzero should never be used for > > them (generic bzero is faster), > > Wrong. I fixed machdep.c to compute and print the bandwidth correctly: Wrong yourself. The fpu is too slow to use for copying for everything except original Pentiums. The bandwidth test is just done to avoid hard- configuring this knowledge. > des@des ~% egrep '(CPU|bzero)' /var/run/dmesg.boot > CPU: AMD-K6(tm) 3D processor (350.80-MHz 586-class CPU) > i586_bzero() bandwidth = 1056759 kBps > bzero() bandwidth = 124211 kBps I don't believe a bandwitdh of 1 GB/sec. It may be possible if the buffer fits in an L1 or on-chip L2 cache (the test buffer is a bit small for today's L2 cache sizes), but then plain bzero() would also benefit from the cache. > > i586_bzero gets used because negative bandwidths are significantly > > smaller than positive ones, > > Uh, Bruce, we pick the method that gives the *highest* bandwidth, not > the lowest. Sorry, I meant "should not get used". > > > so plain bzero is faster according to this > > message, > > There you go contradicting yourself... This part is correct. > Anyway, the bug is not K6-specific - I guess the reason why we're only > seeing it on K6's is that they're the only 586-class CPUs that are > fast enough to still be in widespread use. The bug in i586_bzero() affects anything that gets that far, but only original Pentiums should get that far. Apparently not many people run -current on those. I actually turned on ny P5/133 a week ago, but I didn't notice the bug. The "bug" in npx.c is not really a bug. It's just that the printf was written before %lld was supported in the kernel, so it truncates to long and uses %ld. This shouldn't be a problem until the bandwidth of main memory exceeds 2GB/sec, which won't happen soon (neither will your apparent 1GB/sec bandwidth). However, bugs in microtime() sometime cause the bandwidth to apparently exceed 2GB/sec. It is a feature that huge bandwidths sometimes get printed as negative values -- negative values are more obviously wrong. This is why %ld is used instead of %lu. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message