Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Oct 2005 10:48:45 -0400 (EDT)
From:      Andrew Gallatin <gallatin@cs.duke.edu>
To:        Scott Long <scottl@samsco.org>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, David Xu <davidxu@FreeBSD.org>, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/amd64/amd64 cpu_switch.S machdep.c
Message-ID:  <17237.2893.263419.610951@grasshopper.cs.duke.edu>
In-Reply-To: <4355080C.302@samsco.org>
References:  <200510172310.j9HNAVPL013057@repoman.freebsd.org> <20051018094402.A29138@grasshopper.cs.duke.edu> <435501B9.4070401@samsco.org> <17237.1482.52148.283282@grasshopper.cs.duke.edu> <4355080C.302@samsco.org>

next in thread | previous in thread | raw e-mail | index | archive | help

Scott Long writes:
 > Andrew Gallatin wrote:
 > > As I pointed out in another thread, both linux and solaris do it.
 > > Solaris seems to have a nice algorithm for keeping things in sync, and
 > > accounting for the TSC getting cleared after suspend/resume etc.  At
 > > my level of understanding, this argument is nothing more than "but
 > > Mom, all the other kids are doing it".  I was just hoping that
 > > somebody with real understanding could pick up on it.
 > 
 > Steering mutliple TSC's together isn't that hard and there are plenty of
 > examples, as you point out.  Accounting for the changes due to thermal
 > and power management (note that this isn't the same problem as suspend
 > and resume) is what worries me.

Yes, I have no answer for this :(

 > > Yeah.  I moved my back to hz=1000 when I noticed 4000 interrupts/sec
 > > on an idle system.
 > > 
 > > Drew
 > 
 > Do you mean 1000 or 100 here?  Anyways, the high clock interrupt rate is

Sorry.. That was a typo.  I meant hz=100.

Drew



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17237.2893.263419.610951>