Date: Mon, 19 Mar 2001 15:16:11 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Dag-Erling Smorgrav <des@ofug.org> Cc: David Malone <dwmalone@maths.tcd.ie>, current@FreeBSD.ORG, jhb@FreeBSD.ORG, jake@FreeBSD.ORG, Ian Dowse <iedowse@maths.tcd.ie> Subject: Re: Interesting backtrace... Message-ID: <Pine.BSF.4.21.0103191449460.33565-100000@besplex.bde.org> In-Reply-To: <xzpelvu4nrn.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19 Mar 2001, Dag-Erling Smorgrav wrote: > Bruce Evans <bde@zeta.org.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0103191449460.33565-100000>