From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751264AbdFFGu3 (ORCPT ); Tue, 6 Jun 2017 02:50:29 -0400 Received: from cn.fujitsu.com ([59.151.112.132]:52590 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750755AbdFFGu2 (ORCPT ); Tue, 6 Jun 2017 02:50:28 -0400 X-IronPort-AV: E=Sophos;i="5.22,518,1449504000"; d="scan'208";a="19704247" Subject: Re: [RFC PATCH v3 00/12] Unify interrupt mode and setup it as soon as possible To: Thomas Gleixner References: <1494423889-25799-1-git-send-email-douly.fnst@cn.fujitsu.com> CC: , , , , , , From: Dou Liyang Message-ID: Date: Tue, 6 Jun 2017 14:50:19 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.167.226.106] X-yoursite-MailScanner-ID: 90B9247C6F22.A9C01 X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: douly.fnst@cn.fujitsu.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Thomas, At 05/23/2017 09:29 AM, Dou Liyang wrote: > Dear Thomas, > > At 05/23/2017 04:23 AM, Thomas Gleixner wrote: >> Dou, >> >> On Wed, 10 May 2017, Dou Liyang wrote: >> >>> According to Ingo's and Eric's advice[1,2], Try my best to optimize the >>> init of interrupt delivery mode for x86. >> >> sorry for replying late. The patchset is not forgotten, it's on my todo >> list and I'll tend to it latest next week. >> > > I am very glad to hear that. :) > > I will check it again and wait for your advice. I have come to a code bottleneck. Hope to spend your precious time and let me move on. Following is some test results for that patchset. In a theoretical code analysis, the patchset can wrap the original logic. 1) The original logic of the interrupt delivery mode setup： -Step O_1) Keep in PIC mode or virtual wire mode: Check (smp_found_config || !boot_cpu_has(X86_FEATURE_APIC)) true: PIC mode false: virtual wire mode -Step O_2) Try to switch to symmetric IO mode: O_2_1) In up system: -Check disable_apic ture: *O_S_1* (original situation 1) -Check whether there is a separate or integrated chip don't has: *O_S_2* -Check !smp_found_config ture: *O_S_3* -Others: *O_S_4* O_2_2) In smp-capable system: -Check !smp_found_config && !acpi_lapic true: goto *O_2_1)* -Check if it is LAPIC don't has: *O_S_5* -Check !max_cpus true: *O_S_6* -read_apic_id() != boot_cpu_physical_apicid true: *O_S_7* -Others: *O_S_8* 2) After that patchset, the new logic: -Step N_1) Skip step O_1 and try to switch to the final interrupt mode -Check disable_apic ture: *N_S_1* (New situation 1) -Check whether there is a separate or integrated chip ture: *N_S_2* -Check if (!smp_found_config) ture: *N_S_3* -Check !setup_max_cpus ture: *N_S_4* -Check read_apic_id() != boot_cpu_physical_apicid ture: *N_S_5* -Others: *N_S_6* O_S_1 is covered in N_S_1 O_S_2 is covered in N_S_2 O_S_3 is covered in N_S_3 O_S_4 is covered in N_S_6 O_S_5 is covered in N_S_2 O_S_6 is covered in N_S_4 O_S_7 is covered in N_S_5 O_S_8 is covered in N_S_6 -------------------------------------------- In the actual test, It also can work well in the situations of my test matrix The factors of test matrix: X86 | SMP |LOCAL APIC|I/O APIC|UP_LATE_INIT| ----- |-----|----------|--------|------------| 32-bit| Y | Y | Y | Y | 64-bit| N | N | N | N | disable_apic|X86_FEATURE_APIC|smp_found_config| ------------|----------------|----------------| 0 | 0 | 0 | 1 | 1 | 1 | acpi_lapic|acpi_ioapic|setup_max_cpus| ----------|-----------|--------------| 0 | 0 | =0 | 1 | 1 | >0 | > > Thanks, > Liyang. > >> Thanks, >> >> tglx >> >> >>