Messages in this thread | | | Date | Tue, 6 Jan 2004 04:06:40 +0100 | From | Andi Kleen <> | Subject | Re: [BUG] x86_64 pci_map_sg modifies sg list - fails multiple map/unmaps |
| |
On 05 Jan 2004 18:05:47 -0600 James Bottomley <James.Bottomley@steeleye.com> wrote:
> On Mon, 2004-01-05 at 15:31, Andi Kleen wrote: > > For the sake of bug-to-bug compatibility to the SCSI layer this patch may > > work. I haven't tested it so no guarantees if it won't eat your file systems. > > Feedback welcome anyways. > > This isn't a bug in SCSI, it's a deliberate design feature. SCSI has > certain events, like QUEUE full that cause us to re-queue the pending > I/O. Other block layer drivers that can get these EAGAIN type queueing > problems from the device also follow this model.
It's ok. I fixed the code now[1] If you have other undocumented requirements you should document them though, otherwise there may be more problems. Since merging is disabled by default now it won't trigger anyways.
[1] will be in next merge after testing, the last patch i posted still had one bug.
> As to the idempotence of map/unmap: I'm ambivalent. If it's going to be > a performance hit to return the sg list to its prior state in unmap, > then it does seem a waste given that for most of our I/O transactions we > simply free the sg list after the unmap.
With the evil dma_length trick it is actually near zero cost.
> 1. Fix the x86_64 mapping layer as your patch proposes (how much of a > performance hit on every transaction will this be)?
I don't expect a significant performance hit.
-Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |