| Message ID | 20220627153150.106995-3-ltykernel@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2] swiotlb: Split up single swiotlb lock | expand |
On Mon, Jun 27, 2022 at 11:31:50AM -0400, Tianyu Lan wrote: > From: Tianyu Lan <Tianyu.Lan@microsoft.com> > > When initialize swiotlb bounce buffer, smp_init() has not been > called and cpu number can not be got from num_online_cpus(). > Use the number of lapic entry to set swiotlb area number and > keep swiotlb area number equal to cpu number on the x86 platform. Can we reorder that initialization? Because I really hate having to have an arch hook in every architecture.
On 6/29/2022 10:04 PM, Christoph Hellwig wrote: > On Mon, Jun 27, 2022 at 11:31:50AM -0400, Tianyu Lan wrote: >> From: Tianyu Lan <Tianyu.Lan@microsoft.com> >> >> When initialize swiotlb bounce buffer, smp_init() has not been >> called and cpu number can not be got from num_online_cpus(). >> Use the number of lapic entry to set swiotlb area number and >> keep swiotlb area number equal to cpu number on the x86 platform. > > 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.
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?
On 7/6/2022 5:02 PM, Christoph Hellwig wrote: > On Wed, Jul 06, 2022 at 04:57:33PM +0800, Tianyu Lan wrote: >> 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(). > > Yes. > >> The mem_init() is called before smp_init(). > > But why would that matter? cpu_possible_map is set up from > setup_arch(), which is called before that. Sorry. I just still focus online cpu number and the number is got after smp_init(). Possible cpu number includes some offline cpus. I will have a try. Thanks for suggestion.
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 907cc98b1938..7e13499f2c10 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -22,6 +22,7 @@ #include <linux/efi-bgrt.h> #include <linux/serial_core.h> #include <linux/pgtable.h> +#include <linux/swiotlb.h> #include <asm/e820/api.h> #include <asm/irqdomain.h> @@ -1131,6 +1132,8 @@ static int __init acpi_parse_madt_lapic_entries(void) return count; } + swiotlb_adjust_nareas(max(count, x2count)); + x2count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_X2APIC_NMI, acpi_parse_x2apic_nmi, 0); count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_APIC_NMI,