Re: [PATCH 1/3] dynticks - implement no idle hz for x86

[Srivatsa Vaddagiri <vatsa@in.ibm.com>]

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