public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Mark Salyzyn <Mark_Salyzyn@adaptec.com>
Cc: Matthew Wilcox <matthew@wil.cx>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] Stop using num_physpages in aacraid
Date: Fri, 09 May 2008 09:28:57 -0500	[thread overview]
Message-ID: <1210343337.3069.9.camel@localhost.localdomain> (raw)
In-Reply-To: <FD415073-DC5F-426F-8ADD-09CF96C6917D@adaptec.com>

On Fri, 2008-05-09 at 02:39 -0400, Mark Salyzyn wrote:
> ACK
> 
> with comment, I had chosen to perform the sizeof check as it optimized  
> out the code on the 32 bit platforms and could have merged the  
> aac_scsi_32_64 and aac_scsi_32 functions (such considerations are my  
> penance for writing peephole optimizers and BIOS code in C/C++). Never  
> sacrifice clarity/maintainability for optimization if you can afford it.

Yes ... I wish there were some way of getting the 

dma_get_required_mask() > DMA_32BIT_MASK

to compile out in the 32 bit case.  I'll think about it.


Another thing to note is that your problem could be solved if we could
adjust the queue mask per device (you want a 64 bit mask for the raid
devices and a 32 bit one for the physical ones).  This is analagous to
the ATA MDMA problem with ATA/ATAPI (the protocol can only do 32 bits
with ATAPI but the full 64 bits with ATA).  I'll see if we can use this
as a case to drive a fix for that.

James



  reply	other threads:[~2008-05-09 14:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-02 18:52 [PATCH] Stop using num_physpages in aacraid Matthew Wilcox
2008-05-02 19:06 ` Mark Salyzyn
2008-05-03 10:51   ` Matthew Wilcox
2008-05-05 15:11     ` Mark Salyzyn
2008-05-08 21:18     ` James Bottomley
2008-05-09  6:39       ` Mark Salyzyn
2008-05-09 14:28         ` James Bottomley [this message]
2008-05-09 16:49         ` James Bottomley
2008-05-02 19:45 ` Mark Salyzyn

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=1210343337.3069.9.camel@localhost.localdomain \
    --to=james.bottomley@hansenpartnership.com \
    --cc=Mark_Salyzyn@adaptec.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=matthew@wil.cx \
    /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