[lkml]   [2009]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] configure HAVE_UNSTABLE_SCHED_CLOCK for SGI_SN systems
    On Tue, Jan 06, 2009 at 12:15:34PM -0800, Luck, Tony wrote:
    > >
    > > SGI Altix has unsynchronized itc clocks. This results in rq->clock
    > > occasionally being set to a time in the past by a remote cpu.
    > SGI Altix is definitely the worst offender here. On heterogeneneous
    > systems with different model cpus across nodes the itc rate may differ
    > by hundreds of megahertz. Even when all cpus are at the same rated
    > speed, different nodes are driven from different crystals, so the itc
    > values will slowly drift apart (Linux discovers this from SAL and so
    > doesn't bother to synchronize them).
    > > Note that it is possible that this problem may exist for other ia64
    > > machines as well, based on the following comment for sched_clock() in
    > > arch/ia64/kernel/head.S:
    > >
    > > * Return a CPU-local timestamp in nano-seconds. This timestamp is
    > > * NOT synchronized across CPUs its return value must never be
    > > * compared against the values returned on another CPU. The usage in
    > > * kernel/sched.c ensures that.
    > When sched_clock() was first created this was part of its definition.
    > It meant that sched_clock could be simple & fast because it didn't
    > need to be synchronized across cpus.
    > It seems that new uses have grown for it that no longer allow that
    > flexibility.
    > All ia64 systems are potentially affected ... but perhaps you might
    > never see the problem on most because the itc clocks are synced as close
    > as s/w can get them when cpus are brought on line.

    Do you want Dimitri to resubmit with this set for all IA64 or leave it
    as is?


     \ /
      Last update: 2009-01-06 21:23    [W:0.021 / U:2.584 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site