All of lore.kernel.org
 help / color / mirror / Atom feed
From: bill4carson@gmail.com (bill4carson)
To: kernelnewbies@lists.kernelnewbies.org
Subject: test jiffies on ARM SMP board
Date: Mon, 25 Feb 2013 15:02:39 +0800	[thread overview]
Message-ID: <512B0C8F.30402@gmail.com> (raw)
In-Reply-To: <BLU002-W18453B5FE6CB5CDDA18C8DBCF60@phx.gbl>



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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

-- 
?????????,??????????

--bill

      parent reply	other threads:[~2013-02-25  7:02 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-20 16:39 test jiffies on ARM SMP board buyitian
2013-02-20 17:16 ` Dave Hylands
2013-02-20 17:24 ` anish kumar
2013-02-20 17:24   ` anish kumar
2013-02-20 17:24   ` anish kumar
2013-02-20 17:30   ` Russell King - ARM Linux
2013-02-20 17:30     ` Russell King - ARM Linux
2013-02-20 18:05     ` anish kumar
2013-02-20 18:05       ` anish kumar
2013-02-20 18:05       ` anish kumar
2013-02-25  7:04     ` bill4carson
2013-02-25  7:04       ` bill4carson
2013-02-25  7:04       ` bill4carson
2013-02-21  5:06   ` Mandeep Sandhu
2013-02-21  5:06     ` Mandeep Sandhu
2013-02-21  5:06     ` Mandeep Sandhu
2013-02-25  7:02 ` bill4carson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=512B0C8F.30402@gmail.com \
    --to=bill4carson@gmail.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.