On 7/6/2022 4:00 PM, Christoph Hellwig wrote:
On Fri, Jul 01, 2022 at 01:02:21AM +0800, Tianyu Lan wrote:
Can we reorder that initialization? Because I really hate having
to have an arch hook in every architecture.
How about using "flags" parameter of swiotlb_init() to pass area number
or add new parameter for area number?
I just reposted patch 1 since there is just some coding style issue and area
number may also set via swiotlb kernel parameter. We still need figure out a
good solution to pass area number from architecture code.
What is the problem with calling swiotlb_init after nr_possible_cpus()
works?
Swiotlb_init() is called in the mem_init() of different architects and
memblock free pages are released to the buddy allocator just after
calling swiotlb_init() via memblock_free_all().
The mem_init() is called before smp_init(). If calling swiotlb_init()
after smp_init(), that means we can't allocate large chunk low end
memory via memblock_alloc() in the swiotlb(). Swiotlb_init() needs
to rework to allocate memory from the buddy allocator and just like
swiotlb_init_late() does. This will limit the bounce buffer size.
Otherwise We need to do the reorder for all achitectures and there maybe
some other unknown issues.
swiotlb flags parameter of swiotlb_init() seems to be a good place to
pass the area number in current code. If not set the swiotlb_area
number/flag, the area number will be one and keep the original behavior
of one single global spinlock protecting io tlb data structure.
