BMC/Intel-BMC/linux.git/arch/x86/kernel/smpboot.c, branch dev-4.3

x86 smpboot: Re-enable init_udelay=0 by default on modern CPUs

2016-01-31T19:25:42+00:00

commit 656279a1f3b210cf48ccc572fd7c6b8e2250be77 upstream. commit f1ccd249319e allowed the cmdline "cpu_init_udelay=" to work with all values, including the default of 10000. But in setting the default of 10000, it over-rode the code that sets the delay 0 on modern processors. Also, tidy up use of INT/UINT. Fixes: f1ccd249319e "x86/smpboot: Fix cpu_init_udelay=10000 corner case boot parameter misbehavior" Reported-by: Shane Signed-off-by: Len Brown Cc: dparsons@brightdsl.net Link: http://lkml.kernel.org/r/9082eb809ef40dad02db714759c7aaf618c518d4.1448232494.git.len.brown@intel.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

x86/smpboot: Fix CPU #1 boot timeout

2015-10-19T07:14:41+00:00

The following commit: a9bcaa02a5104ac ("x86/smpboot: Remove SIPI delays from cpu_up()") Caused some Intel Core2 processors to time-out when bringing up CPU #1, resulting in the missing of that CPU after bootup. That patch reduced the SIPI delays from udelay() 300, 200 to udelay() 0, 0 on modern processors. Several Intel(R) Core(TM)2 systems failed to bring up CPU #1 10/10 times after that change. Increasing either of the SIPI delays to udelay(1) results in success. So here we increase both to udelay(10). While this may be 20x slower than the absolute minimum, it is still 20x to 30x faster than the original code. Tested-by: Donald Parsons Tested-by: Shane Signed-off-by: Len Brown Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: dparsons@brightdsl.net Cc: shrybman@teksavvy.com Link: http://lkml.kernel.org/r/6dd554ee8945984d85aafb2ad35793174d068af0.1444968087.git.len.brown@intel.com Signed-off-by: Ingo Molnar

x86/smpboot: Fix cpu_init_udelay=10000 corner case boot parameter misbehavior

2015-10-19T07:14:41+00:00

For legacy machines cpu_init_udelay defaults to 10,000. For modern machines it is set to 0. The user should be able to set cpu_init_udelay to any value on the cmdline, including 10,000. Before this patch, that was seen as "unchanged from default" and thus on a modern machine, the user request was ignored and the delay was set to 0. Signed-off-by: Len Brown Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: dparsons@brightdsl.net Cc: shrybman@teksavvy.com Link: http://lkml.kernel.org/r/de363cdbbcfcca1d22569683f7eb9873e0177251.1444968087.git.len.brown@intel.com Signed-off-by: Ingo Molnar

Merge branch 'x86-cleanups-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2015-09-01T16:33:26+00:00

Pull x86 init code fixlet from Ingo Molnar: "A single change: fix obsolete init code annotations" * 'x86-cleanups-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86: Drop bogus __ref / __refdata annotations

x86/smpboot: Remove APIC.wait_for_init_deassert and atomic init_deasserted

2015-08-17T08:42:28+00:00

Both the per-APIC flag ".wait_for_init_deassert", and the global atomic_t "init_deasserted" are dead code -- remove them. For all APIC types, "wait_for_master()" prevents an AP from proceeding until the BSP has set cpu_callout_mask, making "init_deasserted" {unnecessary}: BSP: ... BSP: {set init_deasserted} AP: wait_for_master() set cpu_initialized_mask wait for cpu_callout_mask BSP: test cpu_initialized_mask BSP: set cpu_callout_mask AP: test cpu_callout_mask AP: {wait for init_deasserted} ... AP: Deleting the {dead code} above is necessary to enable some parallelism in a future patch. Signed-off-by: Len Brown Cc: Andy Lutomirski Cc: Arjan van de Ven Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Dave Hansen Cc: Igor Mammedov Cc: Jan H. Schönherr Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Zhu Guihua Link: http://lkml.kernel.org/r/de4b3a9bab894735e285870b5296da25ee6a8a5a.1439739165.git.len.brown@intel.com Signed-off-by: Ingo Molnar

x86/smpboot: Remove SIPI delays from cpu_up()

2015-08-17T08:42:27+00:00

MPS 1.4 example code shows the following required delays during processor on-lining: INIT udelay(10,000) SIPI udelay(200) SIPI udelay(200) /* Linux actually implements this as udelay(300) */ Linux skips the udelay(10,000) on modern processors. This patch removes the udelay(200) after each SIPI on those same processors. All three legacy delays can be restored by the cmdline "cpu_init_udelay=10000". As measured by analyze_suspend.py, this patch speeds processor resume time on my desktop from 2.4ms to 1.8ms, per AP. Signed-off-by: Len Brown Cc: Andy Lutomirski Cc: Arjan van de Ven Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Dave Hansen Cc: Igor Mammedov Cc: Jan H. Schönherr Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Zhu Guihua Link: http://lkml.kernel.org/r/a5dfdbc8fbfdd813784da204aad5677fe459ac37.1439739165.git.len.brown@intel.com Signed-off-by: Ingo Molnar

x86/smpboot: Remove udelay(100) when polling cpu_callin_map

2015-08-17T08:42:27+00:00

After the BSP sends INIT/SIPI/SIP to the AP and sees the AP in the cpu_initialized_map, it sets the AP loose via the cpu_callout_map, and waits for it via the cpu_callin_map. The BSP polls the cpu_callin_map with a udelay(100) and a schedule() in each iteration. The udelay(100) adds no value. For example, on my 4-CPU dekstop, the AP finishes cpu_callin() in under 70 usec and sets the cpu_callin_mask. The BSP, however, doesn't see that setting until over 30 usec later, because it was still running its udelay(100) when the AP finished. Deleting the udelay(100) in the cpu_callin_mask polling loop, saves from 0 to 100 usec per Application Processor. Signed-off-by: Len Brown Cc: Andy Lutomirski Cc: Arjan van de Ven Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Dave Hansen Cc: Igor Mammedov Cc: Jan H. Schönherr Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Zhu Guihua Link: http://lkml.kernel.org/r/0aade12eabeb89a688c929fe80856eaea0544bb7.1439739165.git.len.brown@intel.com Signed-off-by: Ingo Molnar

x86/smpboot: Remove udelay(100) when polling cpu_initialized_map

2015-08-17T08:42:27+00:00

After the BSP sends the APIC INIT/SIPI/SIPI to the AP, it waits for the AP to come up and indicate that it is alive by setting its own bit in the cpu_initialized_mask. Linux polls for up to 10 seconds for this to happen. Each polling loop has a udelay(100) and a call to schedule(). The udelay(100) adds no value. For example, on my desktop, the BSP waits for the other 3 CPUs to come on line at boot for 305, 404, 405 usec. For resume from S3, it waits 317, 404, 405 usec. But when the udelay(100) is removed, the BSP waits 305, 310, 306 for boot, and 305, 307, 306 for resume. So for both boot and resume, removing the udelay(100) speeds online by about 100us in 2 of 3 cases. Signed-off-by: Len Brown Cc: Andy Lutomirski Cc: Arjan van de Ven Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Dave Hansen Cc: Igor Mammedov Cc: Jan H. Schönherr Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Zhu Guihua Link: http://lkml.kernel.org/r/33ef746c67d2489cad0a9b1958cf71167232ff2b.1439739165.git.len.brown@intel.com Signed-off-by: Ingo Molnar

x86: Drop bogus ref / refdata annotations

2015-07-20T16:57:20+00:00

The __ref / __refdata annotations used to be needed because of referencing functions / variables annotated __cpuinit / __cpuinitdata. But those annotations vanished during the development of v3.11. Therefore most of the __ref / __refdata annotations are not needed anymore. As they may hide legitimate sections mismatches, we better get rid of them. Signed-off-by: Mathias Krause Cc: Borislav Petkov Cc: Paul Gortmaker Cc: Peter Zijlstra Cc: Rafael J. Wysocki Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1437409973-8927-1-git-send-email-minipli@googlemail.com Signed-off-by: Ingo Molnar

genirq: Revert sparse irq locking around __cpu_up() and move it to x86 for now

2015-07-15T08:39:17+00:00

Boris reported that the sparse_irq protection around __cpu_up() in the generic code causes a regression on Xen. Xen allocates interrupts and some more in the xen_cpu_up() function, so it deadlocks on the sparse_irq_lock. There is no simple fix for this and we really should have the protection for all architectures, but for now the only solution is to move it to x86 where actual wreckage due to the lack of protection has been observed. Reported-and-tested-by: Boris Ostrovsky Fixes: a89941816726 'hotplug: Prevent alloc/free of irq descriptors during cpu up/down' Signed-off-by: Thomas Gleixner Cc: Peter Zijlstra Cc: xiao jin Cc: Joerg Roedel Cc: Borislav Petkov Cc: Yanmin Zhang Cc: xen-devel