On Mon, Mar 28, 2016 at 11:55:18AM -0700, John Baldwin wrote:
> I think this is more to allow you to keep the TSCs in sync across cores
> more sanely by being able to adjust TSC_ADJ instead of trying to time
> a write to the TSC to apply an offset (which is racy). If it was targeted
> at SMM, it
On Thursday, March 24, 2016 11:09:17 AM Konstantin Belousov wrote:
> On Wed, Mar 23, 2016 at 02:21:59PM -0700, John Baldwin wrote:
> > As you noted, the issue is if a timecounter needs locks (e.g. i8254) though
> > outside of that I think the patch is great. :-/ Of course, if the TSC
> > isn't
In message <20160328033624.n...@besplex.bde.org>, Bruce Evans writes:
>Of course the details are machine-dependent. My oldest system on which I
>discovered PLL-like behaviour was from late 1997. The PLL might not have
>been in standard bus chips then. It had a K5 (?) running at 233
On Sun, 27 Mar 2016, Poul-Henning Kamp wrote:
In message <20160327130706.ga1...@kib.kiev.ua>, Konstantin Belousov writes:
I haven't seen a single (hardware) system since I started measuring
this 15-20 yeas ago on which the i8524 is not fed from the same clock
as the TSC.
A very
On Mon, Mar 28, 2016 at 04:22:59AM +1100, Bruce Evans wrote:
> On Sun, 27 Mar 2016, Konstantin Belousov wrote:
> > We could even trust CPU report about its frequency as the last resort.
> > From what I saw, the calibrated RTC frequency is very close to the
Err, that should have been TSC, and not
On Sun, 27 Mar 2016, Konstantin Belousov wrote:
On Sun, Mar 27, 2016 at 06:49:40AM +1100, Bruce Evans wrote:
On Sat, 26 Mar 2016, Konstantin Belousov wrote:
On Sat, Mar 26, 2016 at 03:17:43AM +1100, Bruce Evans wrote:
This uses the i8254.
Well, this is the part which I do not like most.
In message <20160327130706.ga1...@kib.kiev.ua>, Konstantin Belousov writes:
>> I haven't seen a single (hardware) system since I started measuring
>> this 15-20 yeas ago on which the i8524 is not fed from the same clock
>> as the TSC.
A very important and relevant detail here is that
On Sun, Mar 27, 2016 at 06:49:40AM +1100, Bruce Evans wrote:
> On Sat, 26 Mar 2016, Konstantin Belousov wrote:
>
> > On Sat, Mar 26, 2016 at 03:17:43AM +1100, Bruce Evans wrote:
> >> This uses the i8254.
> > Well, this is the part which I do not like most. It is ridiculous
> > to calibrate
On Sat, 26 Mar 2016, Konstantin Belousov wrote:
On Sat, Mar 26, 2016 at 03:17:43AM +1100, Bruce Evans wrote:
This uses the i8254.
Well, this is the part which I do not like most. It is ridiculous
to calibrate relatively high-quality CPU oscillator with 8245 timer,
which often fed from
On Sat, Mar 26, 2016 at 03:17:43AM +1100, Bruce Evans wrote:
> This uses the i8254.
Well, this is the part which I do not like most. It is ridiculous
to calibrate relatively high-quality CPU oscillator with 8245 timer,
which often fed from separate, low-quality crystal which currently
selected by
On Fri, 25 Mar 2016, Konstantin Belousov wrote:
On Fri, Mar 25, 2016 at 07:13:54AM +1100, Bruce Evans wrote:
On Thu, 24 Mar 2016, Konstantin Belousov wrote:
[Skipped lock adaptive spinning text for now].
My systems allow speed variations of about 4000:800 = 5:1 for one CPU and
about 50:1
On Fri, Mar 25, 2016 at 07:13:54AM +1100, Bruce Evans wrote:
> On Thu, 24 Mar 2016, Konstantin Belousov wrote:
[Skipped lock adaptive spinning text for now].
>
> >> My systems allow speed variations of about 4000:800 = 5:1 for one CPU and
> >> about 50:1 for different CPUs. So the old method
On Thu, 24 Mar 2016, Konstantin Belousov wrote:
On Fri, Mar 25, 2016 at 01:57:32AM +1100, Bruce Evans wrote:
In fact, if we can use TSC with the only requirement of being monotonic,
I do not see why do we need TSC at all. We can return to pre-r278325
loop, but calibrate the number of loop
On Fri, Mar 25, 2016 at 01:57:32AM +1100, Bruce Evans wrote:
> > In fact, if we can use TSC with the only requirement of being monotonic,
> > I do not see why do we need TSC at all. We can return to pre-r278325
> > loop, but calibrate the number of loop iterations for known delay in
> > 1us, once
On Thu, 24 Mar 2016, Konstantin Belousov wrote:
On Wed, Mar 23, 2016 at 02:21:59PM -0700, John Baldwin wrote:
As you noted, the issue is if a timecounter needs locks (e.g. i8254) though
outside of that I think the patch is great. :-/ Of course, if the TSC
isn't advertised as invariant,
On Wed, Mar 23, 2016 at 02:21:59PM -0700, John Baldwin wrote:
> As you noted, the issue is if a timecounter needs locks (e.g. i8254) though
> outside of that I think the patch is great. :-/ Of course, if the TSC
> isn't advertised as invariant, DELAY() is talking to the timecounter
> directly as
On Wed, 23 Mar 2016, John Baldwin wrote:
On Wednesday, March 23, 2016 09:58:42 AM Konstantin Belousov wrote:
On Mon, Mar 21, 2016 at 11:12:57AM -0700, John Baldwin wrote:
On Saturday, March 19, 2016 05:22:16 AM Konstantin Belousov wrote:
On Fri, Mar 18, 2016 at 07:48:49PM +, John Baldwin
On Wednesday, March 23, 2016 09:58:42 AM Konstantin Belousov wrote:
> On Mon, Mar 21, 2016 at 11:12:57AM -0700, John Baldwin wrote:
> > On Saturday, March 19, 2016 05:22:16 AM Konstantin Belousov wrote:
> > > On Fri, Mar 18, 2016 at 07:48:49PM +, John Baldwin wrote:
> > > >
> > > > -
On Wed, Mar 23, 2016 at 09:58:42AM +0200, Konstantin Belousov wrote:
> If TSC has the behaviour you described, i.e. suddenly jumping random
> steps on single CPU, from the point of view of kernel, then the system
> is seriosly misbehaving. The timekeeping stuff would be badly broken
> regardless
On Mon, Mar 21, 2016 at 11:12:57AM -0700, John Baldwin wrote:
> On Saturday, March 19, 2016 05:22:16 AM Konstantin Belousov wrote:
> > On Fri, Mar 18, 2016 at 07:48:49PM +, John Baldwin wrote:
> > >
> > > - for (x = 0; x < delay; x += 5) {
> > > + for (x = 0; x < delay; x++) {
> > >
On Saturday, March 19, 2016 05:22:16 AM Konstantin Belousov wrote:
> On Fri, Mar 18, 2016 at 07:48:49PM +, John Baldwin wrote:
> >
> > - for (x = 0; x < delay; x += 5) {
> > + for (x = 0; x < delay; x++) {
> > if ((lapic_read_icr_lo() & APIC_DELSTAT_MASK) ==
> >
Author: jhb
Date: Fri Mar 18 19:48:49 2016
New Revision: 297039
URL: https://svnweb.freebsd.org/changeset/base/297039
Log:
Check IPI status more frequently when waiting.
An IPI cannot be sent via the local APIC if a previous IPI is still
being delivered. Attempts to send an IPI will
On Fri, Mar 18, 2016 at 07:48:49PM +, John Baldwin wrote:
>
> - for (x = 0; x < delay; x += 5) {
> + for (x = 0; x < delay; x++) {
> if ((lapic_read_icr_lo() & APIC_DELSTAT_MASK) ==
> APIC_DELSTAT_IDLE)
> return (1);
> -
23 matches
Mail list logo
