I was thinking about this at some point. I think the first step is to
make SWIOTLB use the debugfs to actually print out how much of its
buffers are used - and see if the 64MB is a good fit.
swiotlb is near always wrongly sized. For most system it's far too much,
but for some
not enough. I have some systemtap scripts around to instrument it.
Also it depends on the IO load, so if you size it reasonable you
risk overflow on large IO (however these days this very rarely happens
because
all "serious" IO devices don't need swiotlb anymore)
The other problem is that using only two bits for the needed address
space is also extremly
inefficient (4GB and 16MB on x86). Really want masks everywhere and
optimize for the
actual requirements.
The shrinking part scares me - I think it might be more prudent to first
explore on how to grow it. The big problem looks to allocate a physical
contiguity set of pages. And I guess SWIOTLB would need to change from
using one big region to something of a pool system?
Shrinking: you define a movable zone, so with some delay it can be
always freed.
The problem with swiotlb is however it still cannot block, but it can
adapt to load.
The real fix would be blockable swiotlb, but the way drivers are set up
this is difficult
(at least in kernels using spinlocks)
allocator patchkit,
unfortunately that didn't go forward.
I wasn't present at that time so I don't know what the issues were - you
wouldn't have a link to LKML for this?
There wasn't all that much opposition, but I ran out of time because
fixing the infrastructure
(e.g. getting rid of all of GFP_DMA) is a lot of work. In a sense it's a
big tree sweep project like
getting rid of BKL.
The old patch kit is at ftp://firstfloor.org/pub/ak/dma/
"intro" has the rationale.
I have a slightly newer version of the SCSI & misc drivers patchkit
somewhere.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html