Re: [PATCH 0/4] Use of new scsi_allocate_command

[Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org>]

> But most of what you're doing in that patch set doesn't work.  The whole
> reason for separating the sense buffer from the scsi command is the DMA
> problem of cache line interference caused by doing DMA to an area
> embedded in a structure that has host accessed variables in it.  With
> what you're doing embedding the sense buffer in the internal control
> areas, you're re-introducing that bug.

Hmm if that was really a problem it would be trivial to pad it to cache
lines. On what card did you see that? Also I don't think the current
sense pool is cache line aligned anyways, so there is already
potentially this problem with other data.

Anyways from my audit of the ISA drivers I found that very few (only one
or two) do actually DMA to the sense buffer anyways. Most just memcpy
it from somewhere else. DMA is really the oddball case for the ISA
drivers (that is why with the old unchecked_isa_dma there was a lot of
unnecessary work for this)

> Additionally, it really doesn't make sense for every driver to do a roll
> your own allocator.  

It is only a very small number of drivers. And GFP_DMA in the mid layer
has many problems.

> It makes far more sense for them to be allocated
> centrally (and correctly) so there's only one place it needs fixing if
> there's yet another problem discovered.

The main issue with GFP_DMA in the mid layer (that is why i started my
patchkit originally) was that GFP_DMA does not work very well. First it
means different things on different architectures, then on x86 if you go
outside old legacy ISA drivers the drivers with limited DMA masks
typically don't need 24bit but something larger. I think for such
special situations (again we're talking only about a relatively small
number of drivers) it is much better to do the mapping and allocation in
the low level driver who knows far better what it really needs.

-Andi


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html