[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <33307c790809231402o24c93820tcfbf80d116c729c3@mail.gmail.com>
Date: Tue, 23 Sep 2008 14:02:08 -0700
From: "Martin Bligh" <mbligh@...gle.com>
To: "Thomas Gleixner" <tglx@...utronix.de>
Cc: "Masami Hiramatsu" <mhiramat@...hat.com>,
"Linus Torvalds" <torvalds@...ux-foundation.org>,
"Mathieu Desnoyers" <compudj@...stal.dyndns.org>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
"Steven Rostedt" <rostedt@...dmis.org>, darren@...art.com,
"Frank Ch. Eigler" <fche@...hat.com>,
systemtap-ml <systemtap@...rces.redhat.com>
Subject: Re: Unified tracing buffer
>> I think the tolerance is about 500 cycles. If that's not sufficient, I guess
>> we'll have to either live with some slight misordering (which people have
>> pointed out is kind of inevitable anyway) on these broken machines?
>> It was sufficient for what we were using it for, but maybe not for everyone.
>
> Well, I dont care about the trace reordering at all. I care about user
> space visible time going backwards issues observed via the
> gettimeofday vsyscall. 500 cycles should be fine, I doubt that we can
> migrate in less than that :)
Right, that's what we were interested in.
> I guess you try this only for machines where the TSC runs with
> constant frequency, right ?
We don't do DVFS on the 'broken' TSC machines, just halt.
But yes, it's selective
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists