On Tue, 2003-07-01 at 18:01, Grant Grundler wrote:
> > The bio layer works with
> > a nice finite list of generic or per-queue constraints; it doesn't care
> > currently what the underlying device or IOMMU does.
>
> I don't agree. This whole discussion revolves around getting BIO code and
> IOMMU code to agree on how block merging works for a given platform.
> Using a callback into IOMMU code means the BIO truly doesn't have to know.
> The platform specific IOMMU could just tell BIO code what it wants to
> know (how many SG entries would fit into a limited number of physical
> mappings).
Ah, but the point is that currently the only inputs the IOMMU has to the
bio layer are parameters. I'd like to keep it this way unless there's a
really, really good reason not to. At the moment it seems that the
proposed parameter covers all of IA64's needs and may cover AMD64's as
well.
> > Putting such a callback in would add this entanglement.
>
> yes, sort of. But I think this entanglement is present even for machines
> that don't have an IOMMU because of bounce buffers. But if ia64's swiotlb
> would be made generic to cover buffer bouncing....
Well, not to get into the "where should ZONE_NORMAL end" argument again,
but I was hoping that GFP_DMA32 would elminate the IA64 platform's need
for this. __blk_queue_bounce() strikes me as being much more heavily
exercised than the swiotlb, so I think it should be the one to remain.
It also has more context information to fail gracefully.
James
-
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/
This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:16 EST