From owner-freebsd-current Sun Feb 17 16:27:18 2002 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 11BB937B425 for ; Sun, 17 Feb 2002 16:26:59 -0800 (PST) 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 LAA09636; Mon, 18 Feb 2002 11:26:55 +1100 Date: Mon, 18 Feb 2002 11:26:54 +1100 (EST) From: Bruce Evans X-X-Sender: To: Matthew Dillon Cc: Subject: Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible? In-Reply-To: <200202172025.g1HKPc589840@apollo.backplane.com> Message-ID: <20020218112157.F3970-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 17 Feb 2002, Matthew Dillon wrote: > Ok, I've looked at the code more carefully and I understand how this > works now. However, it is not enough in an SMP environment. You > need a generation count in the timecounter structure and you also need > a synchronization point when you switch time counters or a process > running on a different cpu may wind up using a time counter that is being > actively updated. Er, the comment in patch says it needs a generation count. Unfortunately, we only have half a synchronization point now -- there is a sched_lock() in the update code but nothing in the code that reads the pointer. Maybe a large value of NTIMECOUNTER would help after all. We can afford to o miss a few timecounter changes if we have a lot of timecounter states. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message