All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johan Gunnarsson <johan.gunnarsson@axis.com>
To: "dedekind1@gmail.com" <dedekind1@gmail.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Jesper Nilsson <jespern@axis.com>
Subject: RE: [PATCH 0/2] use hrtimer in nand_wait
Date: Tue, 22 May 2012 10:37:47 +0200	[thread overview]
Message-ID: <A612847CFE53224C91B23E3A5B48BAC7534B129CFD@xmail3.se.axis.com> (raw)
In-Reply-To: <1337671409.2483.98.camel@sauron.fi.intel.com>



> -----Original Message-----
> From: Artem Bityutskiy [mailto:dedekind1@gmail.com]
> Sent: den 22 maj 2012 09:23
> To: Johan Gunnarsson
> Cc: linux-mtd@lists.infradead.org; Jesper Nilsson
> Subject: Re: [PATCH 0/2] use hrtimer in nand_wait
> 
> On Mon, 2012-05-21 at 10:42 +0200, Johan Gunnarsson wrote:
> > I've narrowed it down to the nand_wait routine and its dependency on
> a
> > reliable jiffies counter. Sadly, jiffies is not reliable when
> handling
> > of timer interrupts are delayed or even completely discarded. If
> > interrupts are disabled for, say, 3 timer periods, jiffies will stop
> > counting during this time and have a very fast increment by 3 when
> > interrupts are later enabled.
> 
> I can follow up to this point.
> 
> >  This combined with unfortunate timing can cause the timeout loop
> > think a 20ms timeout is happening when just <0.1ms has passed in wall
> > clock time.
> 
> What is you HZ? Let's say it is 100, then jiffie increments every 10ms,
> right? How can it increment by 2 after 0.1 ms?

It is supposed to increment by 1 each clock tick. But if interrupts are disabled for a number of clock ticks, all these increments will be lumped together and incremented in a loop when interrupts are enabled again. Sort of to catch up.

The relevant parts of the kernel where this happens is

kernel/time/tick_common.c:tick_handle_periodic()
kernel/time/tick_common.c:tick_periodic()
kernel/time/clockevents.c:clockevents_program_event()

Timer interrupt handler calls tick_handle_periodic through the clockevents framework. The loop in tick_handle_periodic will iterate one extra time for each missed tick. clockevents_program_event knows if the next timer to be programmed is in the past by reading back the current HW timer value through the clocksource framework. The actual jiffies increment happens in do_timer through tick_periodic.

Also, please note that we're using a one-shot time that is reprogrammed for each tick. Not a periodic timer.

> >
> > To illustrate the jiffies/interrupt-relationship:
> >
> > Interrupts: |      |      |                    |      |      |      |
> > Jiffies:    |      |      |                    |||    |      |      |
> >
> > This obviously only happen on multi-core CPUs, where the write and
> > interrupts are executed by different cores simultaneously. Switching
> > to hrtimer-based timeout solves this problem for me. I found a second
> > (less serious) issue which included in the first patch.
> 
> Sorry, I do not understand why this happens only on SMP. Could you
> please explain some more?

The only way this can happen is by executing a nand_write at the same time as the jiffy counter is "catching up" (ie. running the loop in tick_handle_periodic as described above.) On a single-core system I don't think that would be possible since the catch-up happens in interrupt context.

> 
> I do not disagree that we should stop using jiffies, if we can, I just
> want to understand what is happening.
> 
> --
> Best Regards,
> Artem Bityutskiy

      reply	other threads:[~2012-05-22  8:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-21  8:42 [PATCH 0/2] use hrtimer in nand_wait Johan Gunnarsson
2012-05-21  8:42 ` [PATCH 1/2] mtd: nand: panic_nand_wait expects timeout in ms Johan Gunnarsson
2012-05-21  8:42 ` [PATCH 2/2] mtd: nand: use hrtimer to measure timeout in nand_wait{_ready, } Johan Gunnarsson
2012-05-22  7:53   ` Artem Bityutskiy
2012-05-22  8:52     ` Johan Gunnarsson
2012-05-22 10:25       ` Artem Bityutskiy
2012-05-22 14:24         ` Johan Gunnarsson
2012-05-22 17:10       ` Ivan Djelic
2012-05-22 18:21         ` Artem Bityutskiy
2012-05-23  6:39         ` Brian Norris
2012-05-23  8:36           ` Ivan Djelic
2012-05-23  8:14         ` Johan Gunnarsson
2012-05-22  7:23 ` [PATCH 0/2] use hrtimer in nand_wait Artem Bityutskiy
2012-05-22  8:37   ` Johan Gunnarsson [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=A612847CFE53224C91B23E3A5B48BAC7534B129CFD@xmail3.se.axis.com \
    --to=johan.gunnarsson@axis.com \
    --cc=dedekind1@gmail.com \
    --cc=jespern@axis.com \
    --cc=linux-mtd@lists.infradead.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.