Re: [PATCH 5/6] swiotlb: Make swiotlb bookkeeping functionsvisible in the header file.

[FUJITA Tomonori]

On Wed, 19 May 2010 08:10:57 +0100
Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote:

> On Wed, May 19, 2010 at 12:34:18PM +0900, FUJITA Tomonori wrote:
> > On Tue, 18 May 2010 18:52:17 +0200
> > Albert Herranz <albert_herranz@xxxxxxxx> wrote:
> > > Every single KB counts on the Wii. It has just 24MB of MEM1 and 64MB of MEM2 (discontiguous memory ranges).
> > > I'm using 1MB for the SWIOTLB for now, but of course that can be further tweaked down.
> > 
> > You can decrease the swiotlb memory however you can't fix the root
> > problems of swiotlb:
> > 
> > - it needs pre-allocated memory
> > - it can't handle the out-of-pre-allocated memory situation.
> 
> That's actually the advantage of swiotlb over dmabounce.  dmabounce's
> dynamic allocation results in OOMs under some IO activity patterns.
> dmabounce also produces the occasional WARN_ON() from the dma coherent
> allocator depending on the driver.

However, we can't guarantee that allocation always succeeds in any IO
patters. And the I/O subsystems and drivers can handle the dma
allocation failure nicely. With SCSI, commands that hit the allocation
failure are re-queued. Nothing bad happens. We shouldn't use WARN_ON
in the dma allocation failure path.

For me, the problems are:

- swiotlb could waste too much pre-allocated memory if there are not
  much IO activities.

- Allocation failure could happen even if the system has lots of free
  memory because swiotlb use only pre-allocated memory.

> We really need to kill off dmabounce.

Agreed. What changes to swiotlb are necessary to replace dmabounce?
Needs to use coherent memory (I'm not sure why dmabounce uses coherent
memory to dma_map_single though)? I'll try to take care of them.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/