From: Jun Sun <jsun@mvista.com>
To: Michael Uhler <uhler@mips.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: [RFC] synchronized CPU count registers on SMP machines
Date: Wed, 4 Jun 2003 16:44:20 -0700 [thread overview]
Message-ID: <20030604164420.I19122@mvista.com> (raw)
In-Reply-To: <002701c32aeb$e4743cd0$08c0a8c0@MIPS.COM>; from uhler@mips.com on Wed, Jun 04, 2003 at 03:51:49PM -0700
On Wed, Jun 04, 2003 at 03:51:49PM -0700, Michael Uhler wrote:
<snip>
> >
> > Apparently, this scheme won't work if any of the following
> > conditions are true:
> >
> > 1) clocks on different CPUs don't have the same frequency
> > 2) clocks on different CPUs drift to each other
>
> Depending on the precise system configuration (including whether the
> CPUs are on different SOCs, different boards, where the PLLs are, and
> what the ultimate clock source is), I'd guess that drift is pretty
> likely on almost all systems unless the clocks are intentionally driven
> by some sort of synchronize source.
>
Yes, if there are physically multiple boards, it is likely to have
drifting clocks.
I don't suppose the count synchronization code will work for
all SMP systems. I hope to get an idea whether it is worth the effort
for the systems that it does work.
For example, it will work on Broadcom's BCM91250 chip and probably a
couple of coming ones.
To give an idea of my original motivation on this RFC, I found out
it is pretty _hard_ just to get a micro-second resolution gettimeofday()
on a SMP system. And apparently this is an issue on other arches
as well. I think i386 uses synchronized TSCs, which is the same
idea as what we are talking about here.
> The biggest problem here is latency on the spinlocks and observation of
> the flag state changing. Depending on the memory architecture, the
> point at which each CPU will see the change could be very different
> (consider a NUMA mesh architecture in which the data movement can take
> different paths). As such, you could see on order of memory latency
> different in the clocks.
>
If it is a few clocks in difference, it should be acceptable.
Basically, imagine a spin lock protected read_count routine:
unsigned read_count()
{
spin_lock(&count_lock);
count = read_c0_count();
spin_unlock(&count_lock);
return count;
}
and imagine there are randomly calls to this function by different
CPUs, the calls are serialized due to the spinlock. As long as
the return values are monotonically increasing, we are fine.
Thanks for the reply. And congrads on your new post. :)
Jun
next prev parent reply other threads:[~2003-06-04 23:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-04 22:39 [RFC] synchronized CPU count registers on SMP machines Jun Sun
2003-06-04 22:51 ` Michael Uhler
2003-06-04 22:51 ` Michael Uhler
2003-06-04 23:44 ` Jun Sun [this message]
2003-06-04 23:15 ` Ralf Baechle
2003-06-04 23:46 ` Jun Sun
2003-06-05 0:12 ` Ralf Baechle
2003-06-05 1:38 ` Jun Sun
2003-06-05 8:09 ` Dominic Sweetman
2003-06-05 8:48 ` Ralf Baechle
2003-06-05 16:53 ` Jun Sun
2003-06-05 20:06 ` Greg Lindahl
2003-06-05 10:45 ` Alan Cox
2003-06-05 8:55 ` Kevin D. Kissell
2003-06-05 8:51 ` Ralf Baechle
2003-06-05 8:55 ` Kevin D. Kissell
2003-06-05 11:08 ` Maciej W. Rozycki
2003-06-05 0:18 ` Keith Owens
[not found] <ralf@linux-mips.org>
2003-06-05 9:23 ` Tor Arntsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030604164420.I19122@mvista.com \
--to=jsun@mvista.com \
--cc=linux-mips@linux-mips.org \
--cc=uhler@mips.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox