All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: "Moore, Eric" <Eric.Moore@lsi.com>
Cc: linux-scsi@vger.kernel.org
Subject: RE: [PATCH 4/9] mpt fusion: error recovery improvements, andsynchronizing internal commands
Date: Tue, 25 Sep 2007 12:34:47 -0500	[thread overview]
Message-ID: <1190741687.3345.30.camel@localhost.localdomain> (raw)
In-Reply-To: <664A4EBB07F29743873A87CF62C26D709D92A4@NAMAIL4.ad.lsil.com>

On Mon, 2007-09-24 at 19:26 -0600, Moore, Eric wrote:
> On Saturday, September 22, 2007 9:39 AM,  James Bottomley wrote:
> > 
> > Well, I'll put this in this time.  However, it contains a 
> > whole slew of
> > pointless changes like this:
> > 
> > 
> > > -                       mdelay (10);
> > > +                       udelay (10000);
> > 
> > and
> > 
> > > -               mdelay(1);
> > > +               udelay(1000);
> > 
> > Which is going to excite the janitors into a frenzy of replace udelay
> > with mdelay patches, which I can well do without ... please don't do
> > this type of change unless there's some actual reason for it.
> > 
> 
> I recall the reason for this change.  I found that medlay called during
> interrupt context didn't work well, whereas udelay did.  Oringally when
> mpt_fault_reset_work was added, this code was called using timers, which
> as you know, is called as part of softirq bottom half handler.  Since
> then, we converted mpt_fault_reset_work to being called using user
> context work task, so really its a non-issue I guess.

That shouldn't have happened ... if you look (include/linux/delay.h)
mdelay is implemented in terms of udelay, so the behaviour should be the
same.

There is a technical difference, though.  Because udelay is busy waiting
in a calculated processor loop, it can overflow for large values (and
large is defined to be anything > 1000) mdelay() is careful to call
udelay multiple times to avoid the potential overflow.

James




      reply	other threads:[~2007-09-25 17:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-18  1:58 [PATCH 4/9] mpt fusion: error recovery improvements, and synchronizing internal commands Eric Moore
2007-09-22 15:38 ` James Bottomley
2007-09-25  1:26   ` [PATCH 4/9] mpt fusion: error recovery improvements, andsynchronizing " Moore, Eric
2007-09-25 17:34     ` James Bottomley [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=1190741687.3345.30.camel@localhost.localdomain \
    --to=james.bottomley@steeleye.com \
    --cc=Eric.Moore@lsi.com \
    --cc=linux-scsi@vger.kernel.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.