You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to the TSC frequency debacle in #3003 MPI_Wtime got switched back to clock_gettime() but opal_timer_linux_find_freq has been left broken. This only affects the one remaining call to opal_timer_base_get_freq left in opal_progress_set_event_poll_rate but I'd like to take a shot at fixing it anyway.
Some alternatives I've been thinking about:
Measure the frequency between a couple of samples of rdtsc and clock_gettime. The longer the period the better, but opal_timer_linux_find_freq doesn't do much so it would take calling usleep for a few µs or taking the measurements elsewhere during opal_init. There's a small difference between sockets, so context switches + migration would be problematic. Ugh.
Take bogomips instead of cpu MHz from /proc/cpuinfo, divide by 2 and hope it keeps working in the future. Linux tries to avoid breaking userspace, so it's probably a safe bet.
Make it a configurable parameter and let users/admins worry about it.
Any comments?
The text was updated successfully, but these errors were encountered:
According to the discussion on the MPI Forum #77 modern Intel processors have rdtsc ticking at the nominal processor frequency, regardless of power saving and frequency boosting (I paraphrased Jim Dinan).
Due to the TSC frequency debacle in #3003 MPI_Wtime got switched back to
clock_gettime()
butopal_timer_linux_find_freq
has been left broken. This only affects the one remaining call toopal_timer_base_get_freq
left inopal_progress_set_event_poll_rate
but I'd like to take a shot at fixing it anyway.Some alternatives I've been thinking about:
rdtsc
andclock_gettime
. The longer the period the better, butopal_timer_linux_find_freq
doesn't do much so it would take callingusleep
for a few µs or taking the measurements elsewhere duringopal_init
. There's a small difference between sockets, so context switches + migration would be problematic. Ugh./proc/cpuinfo
, divide by 2 and hope it keeps working in the future. Linux tries to avoid breaking userspace, so it's probably a safe bet.Any comments?
The text was updated successfully, but these errors were encountered: