>> I wish there was a nicer way to do this ... but looking at the code I can't >> figure out a better way. (no offense John, it's just the way the code is ;) >> ) > > Yeah, I had the same discussion with Peter earlier today. There is > only a rather limited set of options. > > 1) Retrigger the timer interrupt vectors on all CPUs - except the one > we are running on, but we have no interface for that at the moment > > 2) Do the nasty __smp_call_function_single() hack > > Preallocate call_single_data for all cpus and do a > __smp_call_function_single() on all online cpus. > > This can be called from hard interrupt context or irq disabled > regions. > > That would allow to get rid of the whole delay magic all > together. > > Thoughts? >
Both of those options seem like a lot of work for something that happens once every 3-4 years, and may not happen ever again[1]. Based on that statement, if we're going to modify code I would prefer that it be as lightweight as possible. So, in terms of the kernel, option 2 is likely the best way to go rather than introducing new code that will be used once every 3-4 years. I keep asking the question of why the mechanism of inserting a leap second isn't moved into userspace ntpd (or some other appropriate daemon). I suppose there is a risk of ntpd being starved out on heavily loaded systems... P. [1] http://en.wikipedia.org/wiki/Leap_second#Proposal_to_abolish_leap_seconds -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
