Messages in this thread | | | Date | Mon, 26 Sep 2005 20:38:52 +0530 | From | Srivatsa Vaddagiri <> | Subject | Re: [PATCH 1/3] dynticks - implement no idle hz for x86 |
| |
On Fri, Sep 23, 2005 at 12:02:15AM +0530, Srivatsa Vaddagiri wrote: > I feel this is a bit tricky on non-comparator based interrupt sources like > a decrementer on PPC64 or the local APIC timer.
[snip]
> We could consider passing absolute value to 'reprogram' (say 105), like below: > > unsigned int dyn_tick_reprogram_timer(void) > { > int cpu = smp_processor_id(); > unsigned long next, delta, seq; > > cpu_set(cpu, nohz_cpu_mask); > > smp_wmb(); > > if (rcu_pending(cpu) || local_softirq_pending()) { > cpu_clear(cpu, nohz_cpu_mask); > return 0; > } > > do { > read_seqbegin(&xtime_lock); > > next = next_timer_interrupt(); > delta = next - jiffies; > > if (delta < dyn_tick->min_skip) { > cpu_clear(cpu, nohz_cpu_mask); > return 0; > } > > if (delta > dyn_tick->max_skip) > next = jiffies + dyn_tick->max_skip; > > } while (read_seqretry(&xtime_lock, seq)); > > dyn_tick->reprogram(next); > > return delta; > } > > > Since reprogram has to convert it back to some relative number, it will need > to reference jiffy, which makes it racy and require the read_seqbegin/retry > based conversion to relative number. I feel it is lot cleaner in such > a case to just take a write_lock(&xtime_lock) for the whole of > dyn_tick_reprogram_timer.
OTOH, write_seqlock is probably more heavier compared to read_seqlock. So I am OK if we want to call 'reprogram' w/o any xtime_lock held and that routine internally uses a read_seqlock if it wants.
Let me know what you guys think about this and the rest of the interface. If it seems Ok, I can post modified i386 patch based on this interface and would request Martin/Tony to do the S390/ARM ports.
--
Thanks and Regards, Srivatsa Vaddagiri, Linux Technology Center, IBM Software Labs, Bangalore, INDIA - 560017 - 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/
| |