Re: [discuss] Re: [PATCH] Allow all Opteron processors to change pstate at same time

> In contrast, the same machine running with TSC and standard
> PN! sees massive drift, upwards of an hour, within an hour.

Do you see the same drift when you lock date on a single CPU
with taskset?

> If the TSCnow! patch reduces measured drift down to a second 
> a week, would you consider that acceptable?

No because even one second a week will break timing badly
over time. 

I believe the only good solution unless hardware helps would
be to use per CPU TSC offsets as discussed earlier. Even that
is a bit risky because there can be still very small drifts,
but they should be limited by a clock tick error max and
might work out.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

---

• References:
  • RE: [discuss] Re: [PATCH] Allow all Opteron processors to change pstate at same time
    • From: "Langsdorf, Mark" <[email protected]>

• Prev by Date: [PATCH] [fs] Add lock annotation to grab_super
• Next by Date: Re: [patch 2/2] slab: always consider arch mandated alignment
• Previous by thread: RE: [discuss] Re: [PATCH] Allow all Opteron processors to change pstate at same time
• Next by thread: [2.6 patch] make fs/jffs2/nodelist.c:jffs2_obsolete_node_frag() static
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]