From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 1 20:55:59 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id E0D07106566B; Wed, 1 Jun 2011 20:55:58 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Wed, 1 Jun 2011 16:55:49 -0400 User-Agent: KMail/1.6.2 References: <201105241356.45543.jkim@FreeBSD.org> <201105311616.31256.jkim@FreeBSD.org> <4DE5D0D1.1030903@FreeBSD.org> In-Reply-To: <4DE5D0D1.1030903@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106011655.51233.jkim@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: [RFC] Enabling invariant TSC timecounter on SMP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 20:55:59 -0000 On Wednesday 01 June 2011 01:40 am, Andriy Gapon wrote: > on 31/05/2011 23:16 Jung-uk Kim said the following: > > On Tuesday 31 May 2011 07:18 am, Andriy Gapon wrote: > >> on 24/05/2011 20:56 Jung-uk Kim said the following: > >>> I think it's about time to enable invariant TSC timecounter on > >>> SMP by default. Please see the attached patch. It is also > >>> available from here: > >>> > >>> http://people.freebsd.org/~jkim/tsc_smp_test4.diff > >>> > >>> avg convinced me enough that it should be an opt-out feature > >>> going forward. :-) > >> > >> Not sure if I really did that. > >> My position is this: > >> - if we think that TSC is SMP-safe then it should have the best > >> priority > >> - we should do our best to auto-guess if TSC is SMP-safe > >> unless a user explicitly overrides that property (either via > >> explicit testing or by making guesses based on CPU model or etc) > > > > I am sorry if I misunderstood your intention. However, I added > > explicit boot-time TSC sanity check (to do our best to > > auto-guess) and I think TSC is fairly SMP-safe. Hence, I thought > > that it is about time for the change. > > In this case - yes. But I remember that you were thinking about > either improving or simplifying that check or both. Yes, it's still a work-in-progress. However, I thought it is good enough for 9.0 inclusion. BTW, the latest patch is here: http://people.freebsd.org/~jkim/tsc_smp_test5.diff FYI, the only meaningful change from the previous version is that it's limited to AMD single-socket Bulldozer platforms and Intel Core and later platforms. We may add more quirks if needed, of course. > >>> Comments? > >> > >> Perhaps I missed it, but I don't remember the "lowres" part of > >> the patch being discussed. > > > > No, it wasn't discussed with you. Do you see any problem with > > that code? > > I don't see any obvious problem, but I also don't understand > rationale of using smaller max_freq for the ncpus > 1 case. Consecutive RDTSCs used on a same CPU is always incremental but we cannot 100% guarantee that on two cores, even if TSC is derived from the same clock. I am hoping at least latency difference (I believe it's about few tens of cycles max) is "eaten up" by lowering resolution. It's not perfect but it's better than serialization (Linux) or heuristics (OpenSolaris), just because there are few rare conditions to consider. Thoughts? > Maybe these two logical changes should be done as two separate > commits. Will be done. Thanks, Jung-uk Kim