Re: [PATCH] [scsi] Remove __GFP_DMA

2007-05-27 Thread James Bottomley
On Wed, 2007-05-23 at 20:38 +0100, Alan Cox wrote: On Wed, 23 May 2007 15:17:08 -0400 Salyzyn, Mark [EMAIL PROTECTED] wrote: The 31 bit limit for some of these cards is a problem, we currently only do __GFP_DMA for bounce buffer sg elements allocated for user supplied references in

Re: [PATCH] [scsi] Remove __GFP_DMA

2007-05-24 Thread Alan Cox
That didn't used to work right on the AMD boards when I tried it last as we ended up with a buffer that was mapped by the IOMMU for some reason and that was not below 2GB. The physical address you mean? If that is still happening then it needs to get fixed. The allocation should not

RE: [PATCH] [scsi] Remove __GFP_DMA

2007-05-24 Thread Salyzyn, Mark
@vger.kernel.org; Andrew Morton; [EMAIL PROTECTED]; James Bottomley Subject: Re: [PATCH] [scsi] Remove __GFP_DMA On 5/23/07, Christoph Lameter [EMAIL PROTECTED] wrote: On Mon, 21 May 2007, Bernhard Walle wrote: [PATCH] [scsi] Remove __GFP_DMA After

RE: [PATCH] [scsi] Remove __GFP_DMA

2007-05-24 Thread James Bottomley
On Thu, 2007-05-24 at 09:24 -0400, Salyzyn, Mark wrote: So, is the sequence: p = kmalloc(upsg-sg[i].count,GFP_KERNEL); . . . addr = pci_map_single(dev-pdev, p, upsg-sg[i].count, data_dir); Going to ensure that we have a 31 bit (not 32 bit) physical address? No,

RE: [PATCH] [scsi] Remove __GFP_DMA

2007-05-24 Thread Christoph Lameter
On Thu, 24 May 2007, Salyzyn, Mark wrote: So, is the sequence: p = kmalloc(upsg-sg[i].count,GFP_KERNEL); . . . addr = pci_map_single(dev-pdev, p, upsg-sg[i].count, data_dir); Going to ensure that we have a 31 bit (not 32 bit) physical address? Only if you have less

RE: [PATCH] [scsi] Remove __GFP_DMA

2007-05-24 Thread Christoph Lameter
On Thu, 24 May 2007, James Bottomley wrote: Going to ensure that we have a 31 bit (not 32 bit) physical address? No, unfortunately. Implementing kmalloc_mask() and kmalloc_dev() was something I said I'd do ... about two years ago. Tell me more about these ideas. - To unsubscribe from

RE: [PATCH] [scsi] Remove __GFP_DMA

2007-05-24 Thread James Bottomley
On Thu, 2007-05-24 at 10:00 -0700, Christoph Lameter wrote: On Thu, 24 May 2007, James Bottomley wrote: Going to ensure that we have a 31 bit (not 32 bit) physical address? No, unfortunately. Implementing kmalloc_mask() and kmalloc_dev() was something I said I'd do ... about two

RE: [PATCH] [scsi] Remove __GFP_DMA

2007-05-24 Thread Christoph Lameter
On Thu, 24 May 2007, James Bottomley wrote: The idea was basically to match an allocation to a device mask. I was going to do a generic implementation (which would probably kmalloc, check the physaddr and fall back to GFP_DMA if we were unlucky) but allow the architectures to override.

RE: [PATCH] [scsi] Remove __GFP_DMA

2007-05-24 Thread James Bottomley
On Thu, 2007-05-24 at 10:22 -0700, Christoph Lameter wrote: On Thu, 24 May 2007, James Bottomley wrote: The idea was basically to match an allocation to a device mask. I was going to do a generic implementation (which would probably kmalloc, check the physaddr and fall back to GFP_DMA if

Re: [PATCH] [scsi] Remove __GFP_DMA

2007-05-23 Thread James Bottomley
On Wed, 2007-05-23 at 10:41 +0800, Aubrey Li wrote: On 5/23/07, Christoph Lameter [EMAIL PROTECTED] wrote: On Mon, 21 May 2007, Bernhard Walle wrote: [PATCH] [scsi] Remove __GFP_DMA After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to alloate a DMA buffer any

Re: [PATCH] [scsi] Remove __GFP_DMA

2007-05-23 Thread James Bottomley
On Wed, 2007-05-23 at 11:55 -0400, Robert P. J. Day wrote: On Wed, 23 May 2007, James Bottomley wrote: I'll defer to Mark on this one. However, please remember that you can't just blindly remove GFP_DMA ... there are some cards which require it. Aacraid is one example ... it has a

RE: [PATCH] [scsi] Remove __GFP_DMA

2007-05-23 Thread Salyzyn, Mark
; Bernhard Walle; linux-scsi@vger.kernel.org; Andrew Morton; [EMAIL PROTECTED] Subject: Re: [PATCH] [scsi] Remove __GFP_DMA On Wed, 2007-05-23 at 10:41 +0800, Aubrey Li wrote: On 5/23/07, Christoph Lameter [EMAIL PROTECTED] wrote: On Mon, 21 May 2007, Bernhard Walle wrote: [PATCH] [scsi

Re: [PATCH] [scsi] Remove __GFP_DMA

2007-05-23 Thread Alan Cox
On Wed, 23 May 2007 15:17:08 -0400 Salyzyn, Mark [EMAIL PROTECTED] wrote: The 31 bit limit for some of these cards is a problem, we currently only do __GFP_DMA for bounce buffer sg elements allocated for user supplied references in ioctls. I figure we should be using pci_alloc_consistent

Re: [PATCH] [scsi] Remove __GFP_DMA

2007-05-23 Thread Robert Hancock
Alan Cox wrote: On Wed, 23 May 2007 15:17:08 -0400 Salyzyn, Mark [EMAIL PROTECTED] wrote: The 31 bit limit for some of these cards is a problem, we currently only do __GFP_DMA for bounce buffer sg elements allocated for user supplied references in ioctls. I figure we should be using

Re: [PATCH] [scsi] Remove __GFP_DMA

2007-05-22 Thread Christoph Lameter
On Mon, 21 May 2007, Bernhard Walle wrote: [PATCH] [scsi] Remove __GFP_DMA After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to alloate a DMA buffer any more in sd.c. Signed-off-by: Bernhard Walle [EMAIL PROTECTED] Great that avoids a DMA kmalloc slab. Any other

Re: [PATCH] [scsi] Remove __GFP_DMA

2007-05-22 Thread Aubrey Li
On 5/23/07, Christoph Lameter [EMAIL PROTECTED] wrote: On Mon, 21 May 2007, Bernhard Walle wrote: [PATCH] [scsi] Remove __GFP_DMA After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to alloate a DMA buffer any more in sd.c. Signed-off-by: Bernhard Walle [EMAIL PROTECTED]