On Mon, 13 Apr 2015, Preeti U Murthy wrote:
On 04/09/2015 02:48 PM, Thomas Gleixner wrote:
On Thu, 9 Apr 2015, Peter Zijlstra wrote:
On Thu, Apr 09, 2015 at 09:20:39AM +0200, Ingo Molnar wrote:
if at least one base is active (on my fairly standard system all cpus have at least one active hrtimer base all the time - and many cpus have two bases active), then we run hrtimer_get_softirq_time(), which dirties the cachelines of all 4 clock bases:
base->clock_base[HRTIMER_BASE_REALTIME].softirq_time = xtim; base->clock_base[HRTIMER_BASE_MONOTONIC].softirq_time = mono; base->clock_base[HRTIMER_BASE_BOOTTIME].softirq_time = boot; base->clock_base[HRTIMER_BASE_TAI].softirq_time = tai;so in practice we not only touch every cacheline in every timer interrupt, but we _dirty_ them, even the inactive ones.
Urgh we should really _really_ kill that entire softirq mess.
That's the !highres part. We cannot kill that one unless we remove all support for machines which do not provide hardware for highres support.
Now the softirq_time thing is an optimization which we added back in the days when hrtimer went into the tree and Roman complained about the base->get_time() invocation being overkill.
The reasoning behing this was that low resolution systems do not need accurate time for the expiry and the forwarding because everything happens tick aligned.
So for !HIGHRES we have:
static inline ktime_t hrtimer_cb_get_time(struct hrtimer *timer) { return timer->base->softirq_time; }
Why is this called softirq_time when the hrtimer is being serviced in the hard irq context ?
For historical reasons.
Thanks,
tglx