Re: swiotlb detection should be memory hotplug aware ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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


[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux