Date: Wed, 20 Jan 2010 06:19:50 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Attilio Rao <attilio@freebsd.org> Cc: FreeBSD Arch <arch@freebsd.org>, Scott Long <scottl@samsco.org>, Ed Maste <emaste@freebsd.org> Subject: Re: [PATCH] Statclock aliasing by LAPIC Message-ID: <20100120055636.U68115@delplex.bde.org> In-Reply-To: <3bbf2fe11001190941s37f62c48tb91be0061b658b2c@mail.gmail.com> References: <3bbf2fe10911271542h2b179874qa0d9a4a7224dcb2f@mail.gmail.com> <20100116205752.J64514@delplex.bde.org> <3bbf2fe11001160409w1dfdbb9j36458c52d596c92a@mail.gmail.com> <201001191144.23299.jhb@freebsd.org> <3bbf2fe11001190927m10f73775p7b68eb4d3ce0470a@mail.gmail.com> <274B568B-81D9-4554-8C3A-888FF0CD7B08@samsco.org> <3bbf2fe11001190941s37f62c48tb91be0061b658b2c@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 19 Jan 2010, Attilio Rao wrote: > 2010/1/19 Scott Long <scottl@samsco.org>: >> On Jan 19, 2010, at 10:27 AM, Attilio Rao wrote: >>> >>> 2010/1/19 John Baldwin <jhb@freebsd.org>: >>>> My feeling, btw, is that the real solution is to not use a sampling clock >>>> for >>>> per-process stats, but to just use the cycle counter and keep separate >>>> user, >>>> system, and interrupt cycle counts (like the rux_runtime we have now). >>>> This >>>> makes calcru() trivial and eliminates many of the weird "going >>>> backwards", >>>> etc. problems. The only issue with this approach is that not all >>>> platforms >>>> have a cheap cycle counter (many embedded platforms lack one I think), so >>>> you >>>> would almost need to support both modes of operation and maybe have an >>>> #define >>>> in <machine/param.h> to choose between the two modes. >>> >>> Generally that would be a good idea, but the problem is not only for >>> the architectures not supporting it, but also for architectures that >>> do (eg. TSC de-synchronization in some SMP environment). >>> >> >> For process stats, TSC desync isn't a big problem. As a process migrates >> from one CPU to the other, its stats from the old cpu will be recorded, then >> stats will be started on the new cpu. The only problem here is with >> normalizing the different TSC's to a common reference. Maybe that can be >> done when computing cp_times? This is definitely a case where 'perfect' is >> the enemy of 'a hell of a lot better than we have now'. > Only the frequencies would need normalization, since the TSCs are per-CPU and they hopefully don't get reset by suspend etc. Separate frequencies for separate CPUs are not supported now. > I wouldn't like to be mistaken, but IIRC in some benchmarks kris@ did > in the past years we were seeing TSC timers litterally going backwards > after the de-synchronization (even on absolute measurement). Do you really mean individual TSCs going backwards? P-state-invariance (?) should prevent the desync. If the TSCs actually desync, then TSC timecounters are sure to break, with timecounters going backwards being a typical result (certain calculations overflow if time deltas are unexpectedly large). Timecounters used to be used for the equivalent of rux_runtime. There were/are no checks for timecounters themselves going backwards, but sanity checks in the use of rux_runtime detected this. Now TSCs (if available) are normally used for rux_runtime. Recalibration of the TSC's assumed-common frequency is buggy and can easily cause bizarre user times when the frequency is changed. Apart from that, rux_runtime is correct. Good enough for scheduling even when incorrect. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100120055636.U68115>