From owner-cvs-all Tue Apr 17 11: 1:30 2001 Delivered-To: cvs-all@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 9B1CA37B424; Tue, 17 Apr 2001 11:01:24 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3HI1EG11343; Tue, 17 Apr 2001 11:01:14 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200104171753.f3HHrb698820@freefall.freebsd.org> Date: Tue, 17 Apr 2001 11:00:37 -0700 (PDT) From: John Baldwin To: John Baldwin Subject: RE: cvs commit: src/sys/kern kern_clock.c Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17-Apr-01 John Baldwin wrote: > jhb 2001/04/17 10:53:37 PDT > > Modified files: > sys/kern kern_clock.c > Log: > Fix an old bug related to BETTER_CLOCK. Call forward_*clock if SMP > and __i386__ are defined rather than if SMP and BETTER_CLOCK are defined. > The removal of BETTER_CLOCK would have broken this except that kern_clock.c > doesn't include , so it doesn't see the definition of > BETTER_CLOCK, and forward_*clock aren't called, even on 4.x. This seems to > fix the problem where a n-way SMP system would see 100 * n clk interrupts > and 128 * n rtc interrupts. This should probably be fixed in 4.x at some point, as it means clock interrupts aren't getting forwarded to other CPU's. Then again, some parts of hardclock/statclock need to be rethought and redone to work better on SMP. The current practice of forcing a rendezvous with all other CPU's in the system is unfotunate. Also, the loops to do this rendezvous timeout very often on my dual P3-600. I have a feeling that the hard-coded constants are way too small and need to be scaled to the CPU speed. Even better will be when they can go away. Probably just sending an IPI to each CPU to have it do its own clock processing and use spin locks to protect queues of work that get passed off to a swi later on (as the new statclock Jake is working on) will be a better solution for the future. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message