Date: Thu, 14 Oct 1999 00:10:08 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/alpha clock.c interrupt.c Message-ID: <14341.21686.357856.650246@grasshopper.cs.duke.edu> In-Reply-To: <Pine.BSF.4.10.9910141158300.32868-100000@alphplex.bde.org> References: <199910131918.MAA77949@freefall.freebsd.org> <Pine.BSF.4.10.9910141158300.32868-100000@alphplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans writes: > > This mainly weakens the statclock to hide bugs. The most obvious bug is Yes. > that _BSD_CLOCKS_PER_SEC_ was broken on alphas (is 100 but needed to be > 1024 if hz was 1024). It seems to be still broken (is 100 but needs to > be 128 if stathz is 128). However, _BSD_CLOCKS_PER_SEC_ only affects > little-used userland interfaces (e.g, clock(3) and times(3)), so the main So little used that I really wasn't aware of them. Both _BSD_CLK_TCK_ and _BSD_CLOCKS_PER_SEC_ should be changed to 128 if stathz == 128, correct? > bug must be elsewhere. I think there are scaling bugs in schedcpu(), and > NetBSD has fixed them. These bugs may affect all systems with realstathz > != 100. There's a nice commit message detailing what was done at http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/syssrc/sys/kern/kern_synch.c Maybe somebody who's familiar enough with schedcpu to make sense of it could take a look at what they've done.. Thanks, Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14341.21686.357856.650246>