Mark Lord wrote:
Benjamin Herrenschmidt wrote:
On Tue, 2008-02-26 at 00:43 -0500, Mark Lord wrote:
I suppose so. I don't remember all of the details, but iirc, it has to
do with crossing 64K boundaries. Some controllers can't handle it.
It's not only the _size_ of the segments, it's their alig
Benjamin Herrenschmidt wrote:
On Tue, 2008-02-26 at 00:43 -0500, Mark Lord wrote:
I suppose so. I don't remember all of the details, but iirc, it has to
do with crossing 64K boundaries. Some controllers can't handle it.
It's not only the _size_ of the segments, it's their alignment.
The iommu
On Tue, 2008-02-26 at 16:47 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2008-02-26 at 00:43 -0500, Mark Lord wrote:
> > > I suppose so. I don't remember all of the details, but iirc, it has to
> > > do with crossing 64K boundaries. Some controllers can't handle it.
> > >
> > > It's not only th
On Tue, 2008-02-26 at 00:43 -0500, Mark Lord wrote:
> > I suppose so. I don't remember all of the details, but iirc, it has to
> > do with crossing 64K boundaries. Some controllers can't handle it.
> >
> > It's not only the _size_ of the segments, it's their alignment.
> >
> > The iommu will not
Benjamin Herrenschmidt wrote:
On Mon, 2008-02-25 at 23:38 -0500, Mark Lord wrote:
Benjamin Herrenschmidt wrote:
James B. suggests that we stick a WARN_ON() into libata to let us
know if that precondition is violated. Sounds like an easy thing to do
for a couple of -rc cycles someday.
If the
On Mon, 2008-02-25 at 23:38 -0500, Mark Lord wrote:
> Benjamin Herrenschmidt wrote:
> >> James B. suggests that we stick a WARN_ON() into libata to let us
> >> know if that precondition is violated. Sounds like an easy thing to do
> >> for a couple of -rc cycles someday.
> >
> > If the block la
Benjamin Herrenschmidt wrote:
James B. suggests that we stick a WARN_ON() into libata to let us
know if that precondition is violated. Sounds like an easy thing to do
for a couple of -rc cycles someday.
If the block layer gives us a 32k block aligned on a 32k boundary
(aligned), we have no gu
> James B. suggests that we stick a WARN_ON() into libata to let us
> know if that precondition is violated. Sounds like an easy thing to do
> for a couple of -rc cycles someday.
If the block layer gives us a 32k block aligned on a 32k boundary
(aligned), we have no guarantee that the iommu wil
> The block layer uses seg_boundary_mask to ensure that we never have
> to split them again in the LLD.
>
> A very long time ago, when I wrote the IDE DMA code, this was not the case.
Not good enough, still, because the boundaries can change due to the
iommu merging, thus the split must be re-do
Mark Lord wrote:
Benjamin Herrenschmidt wrote:
..
The split wasn't done by the iommu. The split was done by the IDE code
itself to handle the stupid 64k crossing thingy. If it's done
differently now, it might be possible to remove it, I haven't looked.
..
The block layer uses seg_boundary_mas
Benjamin Herrenschmidt wrote:
On Mon, 2008-02-25 at 19:15 -0500, Jeff Garzik wrote:
Mark Lord wrote:
Jeff,
We had a discussion here today about IOMMUs,
and they *never* split sg list entries -- they only ever *merge*.
And this happens only after the block layer has
already done merging while
On Mon, 2008-02-25 at 19:15 -0500, Jeff Garzik wrote:
> Mark Lord wrote:
> > Jeff,
> >
> > We had a discussion here today about IOMMUs,
> > and they *never* split sg list entries -- they only ever *merge*.
> >
> > And this happens only after the block layer has
> > already done merging while res
Jeff Garzik wrote:
As an aside, ISTR tomo-san was working on eliminating the need for the
"/2" by tackling the details on the IOMMU side...
..
Yes, tomo-san just led a nice detailed discussion of it here at LSF'08,
and he agrees that even today it shouldn't affect us that way.
Cheers
-
To unsu
Jeff Garzik wrote:
Mark Lord wrote:
Jeff,
We had a discussion here today about IOMMUs,
and they *never* split sg list entries -- they only ever *merge*.
And this happens only after the block layer has
already done merging while respecting q->seg_boundary_mask.
So worst case, the IOMMU may mer
As an aside, ISTR tomo-san was working on eliminating the need for the
"/2" by tackling the details on the IOMMU side...
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel
Mark Lord wrote:
Jeff,
We had a discussion here today about IOMMUs,
and they *never* split sg list entries -- they only ever *merge*.
And this happens only after the block layer has
already done merging while respecting q->seg_boundary_mask.
So worst case, the IOMMU may merge everything, and t
Jeff,
We had a discussion here today about IOMMUs,
and they *never* split sg list entries -- they only ever *merge*.
And this happens only after the block layer has
already done merging while respecting q->seg_boundary_mask.
So worst case, the IOMMU may merge everything, and then in
libata we u
17 matches
Mail list logo
