public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Brian King <brking@us.ibm.com>
Cc: "Bagalkote, Sreenivas" <sreenib@lsil.com>,
	"'Matt_Domsch@dell.com'" <Matt_Domsch@dell.com>,
	"'paul@kungfoocoder.org'" <paul@kungfoocoder.org>,
	"Mukker, Atul" <Atulm@lsil.com>,
	"'James.Bottomley@SteelEye.com'" <James.Bottomley@SteelEye.com>,
	"'arjanv@redhat.com'" <arjanv@redhat.com>,
	"'linux-scsi@vger.kernel.org'" <linux-scsi@vger.kernel.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH][RELEASE]: megaraid unified driver version 2.20.0.B1
Date: Fri, 16 Apr 2004 14:30:38 -0400	[thread overview]
Message-ID: <4080264E.2040506@pobox.com> (raw)
In-Reply-To: <408024CA.8000401@us.ibm.com>

Brian King wrote:
> Jeff Garzik wrote:
> 
>> 6) Kill uses of "volatile".  _Most_ of the time, this indicates buggy 
>> code.  You should have the proper barriers in place:  mb(), wmb(), 
>> rmb(), barrier(), and cpu_relax().  This has been mentioned before :)
> 
> 
> I'm not sure I totally agree with this statement. I took a quick look at 
> the driver
> and the volatile appears to be used to point to host memory that is 
> modified
> by the adapter. Correct me if I am wrong, but memory barriers will not 
> accomplish
> what the volatile will in this situation.


You are wrong :)  Compare the underlying asm.

Proper use of barriers tells the compiler when it cannot cache certain 
loads and stores in registers.  'volatile' is an atomic bomb to the 
compiler, killing many valid optimizations while (sometimes) hiding 
bugs.  It almost always indicates that the programmer did not bother 
thinking about when and where DMA memory needs to be accessed.

	Jeff




  reply	other threads:[~2004-04-16 18:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <0E3FA95632D6D047BA649F95DAB60E570230C7DB@exa-atlanta.se.lsil.com>
2004-04-16 18:01 ` [PATCH][RELEASE]: megaraid unified driver version 2.20.0.B1 Jeff Garzik
2004-04-16 18:24   ` Brian King
2004-04-16 18:30     ` Jeff Garzik [this message]
2004-04-16 22:50 Mukker, Atul
2004-04-16 23:38 ` Jeff Garzik
  -- strict thread matches above, loose matches on Subject: below --
2004-04-17  6:40 Mukker, Atul
2004-04-17 13:11 ` Ingo Oeser
2004-04-18 14:00 ` Matt Domsch

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=4080264E.2040506@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=Atulm@lsil.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=Matt_Domsch@dell.com \
    --cc=arjanv@redhat.com \
    --cc=brking@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=paul@kungfoocoder.org \
    --cc=sreenib@lsil.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox