* Re: asymmetric multiprocessing [not found] <Pine.LNX.4.33.0112200912480.7795-100000@coffee.psychology.mcmaster.ca> @ 2001-12-20 14:33 ` Martin A. Brooks 2001-12-20 22:32 ` george anzinger 0 siblings, 1 reply; 2+ messages in thread From: Martin A. Brooks @ 2001-12-20 14:33 UTC (permalink / raw) To: Mark Hahn; +Cc: LKML [-- Attachment #1: Type: text/plain, Size: 707 bytes --] On Thu, 2001-12-20 at 14:13, Mark Hahn wrote: > not supported (and frowned upon by the spec). the issue is TSC, > of course, and it's definitely not clear whether the normal case > (correctly configured SMP) should be burdoned by support for > mixed-clock chips. I'm no expert on MP, hence I fail to see why differing clock speeds between CPUs should be a problem providing the system bus rates are constant. As each CPU would be rated differently as far as bogomips are concerned, couldn't the scheduler apply load accordingly? -- Martin A. Brooks Systems Administrator Jtrix Ltd t: +44 7395 4990 57-59 Neal Street f: +44 7395 4991 London, WC2H 9PP e: martin@jtrix.com [-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --] ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: asymmetric multiprocessing 2001-12-20 14:33 ` asymmetric multiprocessing Martin A. Brooks @ 2001-12-20 22:32 ` george anzinger 0 siblings, 0 replies; 2+ messages in thread From: george anzinger @ 2001-12-20 22:32 UTC (permalink / raw) To: Martin A. Brooks; +Cc: Mark Hahn, LKML "Martin A. Brooks" wrote: > > On Thu, 2001-12-20 at 14:13, Mark Hahn wrote: > > not supported (and frowned upon by the spec). the issue is TSC, > > of course, and it's definitely not clear whether the normal case > > (correctly configured SMP) should be burdoned by support for > > mixed-clock chips. > > I'm no expert on MP, hence I fail to see why differing clock speeds > between CPUs should be a problem providing the system bus rates are > constant. As each CPU would be rated differently as far as bogomips are > concerned, couldn't the scheduler apply load accordingly? > But then you are forcing the system to include cpu information each time it reads the TSC. For example, the TSC is currently used to provide the sub jiffie resolution for the system clock. If you also need to include which cpu you run into a couple of problems: a) what if the start TSC is read from a different cpu than the end TSC? (In this case the start is the last jiffie interrupt and the end is "now" when the time is being requested.) b.) The conversion to micro seconds depends on the clock rate, i.e. the TSC clock rate. -- George george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2001-12-20 22:34 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <Pine.LNX.4.33.0112200912480.7795-100000@coffee.psychology.mcmaster.ca>
2001-12-20 14:33 ` asymmetric multiprocessing Martin A. Brooks
2001-12-20 22:32 ` george anzinger
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox