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
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
> > 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
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