lkml.org 
[lkml]   [2005]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.12-mm1 boot failure on NUMA box.

* Martin J. Bligh <Martin.Bligh@us.ibm.com> wrote:

> > is the only problem the unsyncedness? That should be fine as far as the
> > scheduler is concerned. (we compensate for per-CPU drifts)
>
> Well, I think so. But I don't see how you're going to compensate for
> large-scale unsynced-ness safely. I've always completely avoided the
> TSC altogether on NUMA-Q ... would prefer to keep it that way. We got
> lots of wierd random crashes, panics, hangs, and -ve time offsets
> returned from userspace time commands last time I tried it.

ok. Would be nice to check whether reverting that single change solves
the boot problem. If it does i'll switch the measurement method to be
do_gettimeoffset based, that way the measurement will still be accurate.
(which is needed for precise migration cost results) Right now the
calibration uses sched_clock() - which was the reason for the change.

(btw., if the TSC is that unreliable on numaq boxes, shouldnt we disable
it for userspace apps too? Or are those hangs purely kernel bugs? In
which case it might make sense to debug those a bit more - large-scale
TSC unsyncedness is something that could slip in on other hardware too.)

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

\
 
 \ /
  Last update: 2005-06-25 06:06    [W:0.481 / U:0.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site