On 2013年02月21日 00:39, buyitian wrote:
> i am confused about my test. in one device driver,
> i put below code:
>
> printk("start to test test jiffies\n");
>
> local_irq_save(flags);
>
> jf1 = jiffies; // read jiffies first time
>
> // hold cpu for about 2 seconds(do some calculation)
>
> jf2 = jiffies; // read jiffies after 2 seconds
>
> local_irq_restore(flags);
>
> printk("jf1:%lu, jf2:%lu\n", jf1, jf2);
>
> and the output is as below:
>
> <4>[ 108.551124]start to test test jiffies
> <4>[ 110.367604]jf1:4294948151, jf2:4294948151
>
> the jf1 and jf2 are the same value, although they are
> read between 2 seconds interval, i think this is because
> i disabled local interrupt.
> but the printk timestamp is from 108.551124 to 110.367604,
> which is about 2 seconds. and on my platform, printk timestamp
> is got from the function read_sched_clock:
> static u32 __read_mostly (*read_sched_clock)(void) = jiffy_sched_clock_read;
>
> and function jiffy_sched_clock_read() is to read from jiffies.
>
> it seems that the jiffies is frozen when local irq is disabled,
> but after local_irq_restore(), the jiffies not only start
> to run, but also recover the lost 2 seconds.
>
> is the jiffies updated from another cpu when irq is disabled on
> local cpu?
>
> is there some internel processor interrupt between cpu1 and cpu0
> after local irq is re-enabled so that jiffies recover the lost 2 seconds?
80 /*
81 * Event handler for periodic ticks
82 */
83 void tick_handle_periodic(struct clock_event_device *dev)
84 {
85 int cpu = smp_processor_id();
86 ktime_t next;
87
88 tick_periodic(cpu);
89
90 if (dev->mode != CLOCK_EVT_MODE_ONESHOT)
91 return;
92 /*
93 * Setup the next period for devices, which do not have
94 * periodic mode:
95 */
96 next = ktime_add(dev->next_event, tick_period);
97 for (;;) {
98 if (!clockevents_program_event(dev, next, ktime_get())) <--- once irq enabled, here we got -ETIME, then
99 return;
100 /*
101 * Have to be careful here. If we're in oneshot mode,
102 * before we call tick_periodic() in a loop, we need
103 * to be sure we're using a real hardware clocksource.
104 * Otherwise we could get trapped in an infinite
105 * loop, as the tick_periodic() increments jiffies,
106 * when then will increment time, posibly causing
107 * the loop to trigger again and again.
108 */
109 if (timekeeping_valid_for_hres())
110 tick_periodic(cpu); <---- here, we add missing jiffies
111 next = ktime_add(next, tick_period);
112 }
113 }
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@xxxxxxxxxxxxxxxxx
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
--
八百里秦川尘土飞扬,三千万老陕齐吼秦腔。
--bill
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
