Re: RCU stall on panda
On 05/16/2014 09:37 PM, Santosh Shilimkar wrote: On Friday 16 May 2014 03:41 AM, Alex Shi wrote: On 05/16/2014 02:36 AM, Santosh Shilimkar wrote: yes. My board is panda ES. without this revert, it works. Care to specify what linux version you are testing against? Does it hang in idle always immediately on booting? Or does the serial console first hang with sysrq still working (ctrl-a h in minicom for help) with device eventually locking up hard? I just posted an updated patch Alex on other thread. Attaching here again for your reference. Please try it out and see if the you still get a hang. it does not hang this time. This is good news and exactly what I expected. but I am not sure it can solve my problem, since RCU stall is not easy to reproduce in short time. You may want to run the system longer if you can. I suspect the RCU stall was also side effect of missing interrupts. Sure. it do remove the RCU stall on my panda board. Regards, Santosh -- Thanks Alex -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RCU stall on panda
On 05/16/2014 02:36 AM, Santosh Shilimkar wrote: yes. My board is panda ES. without this revert, it works. Care to specify what linux version you are testing against? Does it hang in idle always immediately on booting? Or does the serial console first hang with sysrq still working (ctrl-a h in minicom for help) with device eventually locking up hard? I just posted an updated patch Alex on other thread. Attaching here again for your reference. Please try it out and see if the you still get a hang. it does not hang this time. but I am not sure it can solve my problem, since RCU stall is not easy to reproduce in short time. -- Thanks Alex -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RCU stall on panda
On 05/13/2014 11:32 PM, Tony Lindgren wrote: * Alex Shi alex@linaro.org [140512 23:37]: On 05/13/2014 05:21 AM, Tony Lindgren wrote: * Paul E. McKenney paul...@linux.vnet.ibm.com [140505 11:11]: On Mon, May 05, 2014 at 05:39:43PM +0800, Alex Shi wrote: I keep seeing the RCU stall problem on panda board from 3.10 kernel to latest upstream kernel and google find some one report it before: https://lkml.org/lkml/2012/9/20/519 Is it the hardware issue or a real software problem? I cannot distinguish between hardware and software from the trace below, but given that you are also seeing a soft lockup, either way you do appear to have a real problem as opposed to an RCU CPU stall warning false positive. Looks like you have CPU_IDLE enabled on panda. Hangs with current linux next with CPU_IDLE are currently being discussed on the linux-omap list in thread omap4-panda-es boot issues with v3.15-rc4 I've seen occasional system hangs, and I've also noticed that doing ctrl-a-f h or ctrl-a-f l for sysrq backtrace can unlock the system producing similar errors to the below. Thanks a lot for the info. In fact, the oops keeps in upstream kernel from 3.10 to latest. Care to test if the revert of commit cb7094 Santosh posted as [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled solves the problem for you? After enable this patch, system maybe hang in idle. :( Regards, Tony -- Thanks Alex -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RCU stall on panda
On 05/15/2014 05:05 PM, Daniel Lezcano wrote: After enable this patch, system maybe hang in idle. :( Hi Alex, do you mean even with this revert applied, the board hangs in idle ? yes. My board is panda ES. without this revert, it works. -- Thanks Alex -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled
On 05/16/2014 02:29 AM, Santosh Shilimkar wrote: Alex, Please give a try with your test-case and see if you still see the hang. Am just curious about your issue and hence the request.. there is no test case. I just patched your patches, then boot new kernel, system quickly to hang without any serial port oops, I am using pandaES/ubuntu. -- Thanks Alex -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RCU stall on panda
On 05/13/2014 05:21 AM, Tony Lindgren wrote: * Paul E. McKenney paul...@linux.vnet.ibm.com [140505 11:11]: On Mon, May 05, 2014 at 05:39:43PM +0800, Alex Shi wrote: I keep seeing the RCU stall problem on panda board from 3.10 kernel to latest upstream kernel and google find some one report it before: https://lkml.org/lkml/2012/9/20/519 Is it the hardware issue or a real software problem? I cannot distinguish between hardware and software from the trace below, but given that you are also seeing a soft lockup, either way you do appear to have a real problem as opposed to an RCU CPU stall warning false positive. Looks like you have CPU_IDLE enabled on panda. Hangs with current linux next with CPU_IDLE are currently being discussed on the linux-omap list in thread omap4-panda-es boot issues with v3.15-rc4 I've seen occasional system hangs, and I've also noticed that doing ctrl-a-f h or ctrl-a-f l for sysrq backtrace can unlock the system producing similar errors to the below. Thanks a lot for the info. In fact, the oops keeps in upstream kernel from 3.10 to latest. Regards, Tony 95.519653] INFO: rcu_sched self-detected stall on CPU^M [ 95.519866] 1: (1 GPs behind) idle=2e7/1/0 softirq=4404/4405 ^M [ 95.526489] INFO: rcu_sched detected stalls on CPUs/tasks:^M [ 95.526489] 1: (1 GPs behind) idle=2e7/1/0 softirq=4404/4405 ^M [ 95.526489] (detected by 0, t=4229 jiffies, g=800, c=799, q=440)^M [ 95.526519] Task dump for CPU 1:^M [ 95.526519] swapper/1 R running 0 0 1 0x^M [ 95.559844] (t=4229 jiffies g=800 c=799 q=440)^M [ 95.564727] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.15.0-rc4 #93^M [ 95.571502] [c00133fd] (unwind_backtrace) from [c001076d] (show_stack+0x11/0x14)^M [ 95.579711] [c001076d] (show_stack) from [c0570465] (dump_stack+0x75/0x88)^M [ 95.587371] [c0570465] (dump_stack) from [c0084383] (rcu_check_callbacks+0x353/0x79c)^M [ 95.596038] [c0084383] (rcu_check_callbacks) from [c003e99f] (update_process_times+0x33/0x4c)^M [ 95.605438] [c003e99f] (update_process_times) from [c008e5a3] (tick_sched_handle.isra.18+0x1f/0x48)^M [ 95.615386] [c008e5a3] (tick_sched_handle.isra.18) from [c008e609] (tick_sched_timer+0x3d/0x5c)^M [ 95.624969] [c008e609] (tick_sched_timer) from [c0051a23] (__run_hrtimer+0x67/0x310)^M [ 95.633544] [c0051a23] (__run_hrtimer) from [c00525fd] (hrtimer_interrupt+0xe1/0x214)^M [ 95.642211] [c00525fd] (hrtimer_interrupt) from [c008cecb] (tick_receive_broadcast+0x1f/0x30)^M [ 95.651611] [c008cecb] (tick_receive_broadcast) from [c0011e4f] (handle_IPI+0xb3/0x120)^M [ 95.660461] [c0011e4f] (handle_IPI) from [c00085e5] (gic_handle_irq+0x51/0x54)^M [ 95.668487] [c00085e5] (gic_handle_irq) from [c057603f] (__irq_svc+0x3f/0x64)^M [ 95.676391] Exception stack(0xee0dbf10 to 0xee0dbf58)^M [ 95.681762] bf00: 0001 0001 ee0d8c40^M [ 95.690429] bf20: 3c6bd296 0016 3c6f8c43 0016 eefab540 c08e0c84 c0fc7114^M [ 95.699066] bf40: 0010 ee0dbf58 c006ef4d c0443890 4033 ^M [ 95.706085] [c057603f] (__irq_svc) from [c0443890] (cpuidle_enter_state+0xc0/0xc4)^M [ 95.714477] [c0443890] (cpuidle_enter_state) from [c0444d11] (cpuidle_enter_state_coupled+0xe1/0x290)^M [ 95.724639] [c0444d11] (cpuidle_enter_state_coupled) from [c0067cd1] (cpu_startup_entry+0x1a5/0x494)^M [ 95.734680] [c0067cd1] (cpu_startup_entry) from [80008685] (0x80008685)^M [ 95.742095] BUG: soft lockup - CPU#1 stuck for 40s! [swapper/1:0]^M [ 95.748535] Modules linked in:^M [ 95.751770] irq event stamp: 128730^M [ 95.755462] hardirqs last enabled at (128727): [c044388f] cpuidle_enter_state+0xbf/0xc4^M [ 95.764221] hardirqs last disabled at (128728): [c0576033] __irq_svc+0x33/0x64^M [ 95.772064] softirqs last enabled at (128730): [c00386cd] irq_enter+0x59/0x60^M [ 95.779907] softirqs last disabled at (128729): [c00386ba] irq_enter+0x46/0x60^M [ 95.787750] ^M my RCU and IDLE related kernel config as blow: CONFIG_TREE_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 CONFIG_TREE_RCU_TRACE=y CONFIG_PROVE_RCU=y CONFIG_PROVE_RCU_REPEATEDLY=y CONFIG_SPARSE_RCU_POINTER=y CONFIG_RCU_CPU_STALL_TIMEOUT=21 CONFIG_RCU_CPU_STALL_INFO=y CONFIG_RCU_TRACE=y alexs@alex-panda:~$ cat /proc/config.gz | gunzip | grep IDLE CONFIG_NO_HZ_IDLE=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_GENERIC_IDLE_POLL_SETUP=y CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED=y -- Thanks Alex ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Thanks Alex -- To unsubscribe from this list: send the line unsubscribe linux-omap
[PATCH 09/19] arm: dts: add omap4 CPU thermal data
From: Eduardo Valentin eduardo.valen...@ti.com
This patch changes a dtsi file to contain the thermal data
for MPU domain on OMAP4 and later SoCs. This data will
enable the passive cooling with CPUfreq cooling device
at 100C and the system will do a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
(cherry picked from commit 0bbf6c54d100836db40ba020b7c9793ea3e6be0b)
Signed-off-by: Alex Shi alex@linaro.org
---
arch/arm/boot/dts/omap4-cpu-thermal.dtsi | 41
1 file changed, 41 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4-cpu-thermal.dtsi
diff --git a/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
new file mode 100644
index 000..cb9458f
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
@@ -0,0 +1,41 @@
+/*
+ * Device Tree Source for OMAP4/5 SoC CPU thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include dt-bindings/thermal/thermal.h
+
+cpu_thermal: cpu_thermal {
+ polling-delay-passive = 250; /* milliseconds */
+ polling-delay = 1000; /* milliseconds */
+
+ /* sensor ID */
+thermal-sensors = bandgap 0;
+
+trips {
+cpu_alert0: cpu_alert {
+temperature = 10; /* millicelsius */
+hysteresis = 2000; /* millicelsius */
+type = passive;
+};
+cpu_crit: cpu_crit {
+temperature = 125000; /* millicelsius */
+hysteresis = 2000; /* millicelsius */
+type = critical;
+};
+};
+
+ cooling-maps {
+ map0 {
+ trip = cpu_alert0;
+ cooling-device =
+ cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT;
+ };
+ };
+};
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/19] arm: dts: add omap5 GPU thermal data
From: Eduardo Valentin eduardo.valen...@ti.com
This patch changes a dtsi file to contain the thermal data
for GPU domain on OMAP5 and later SoCs. This data will
enable a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
(cherry picked from commit 28c90169f1d5eabf503e356c76bf49a67aef4cc0)
Signed-off-by: Alex Shi alex@linaro.org
---
arch/arm/boot/dts/omap5-gpu-thermal.dtsi | 28
1 file changed, 28 insertions(+)
create mode 100644 arch/arm/boot/dts/omap5-gpu-thermal.dtsi
diff --git a/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
new file mode 100644
index 000..1b87aca
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for OMAP543x SoC GPU thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include dt-bindings/thermal/thermal.h
+
+gpu_thermal: gpu_thermal {
+ polling-delay-passive = 250; /* milliseconds */
+ polling-delay = 1000; /* milliseconds */
+
+ /* sensor ID */
+ thermal-sensors = bandgap 1;
+
+ trips {
+ gpu_crit: gpu_crit {
+ temperature = 125000; /* milliCelsius */
+ hysteresis = 2000; /* milliCelsius */
+ type = critical;
+ };
+ };
+};
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/19] arm: dts: add cooling properties on omap4460 cpu node
From: Eduardo Valentin eduardo.valen...@ti.com OMAP4460 devices can reach high temperatures and thus needs to have cpufreq-cooling on systems running on it. This patch adds the required cooling device properties so that cpufreq-cpu0 driver loads the cooling device. Cc: Benoît Cousson bcous...@baylibre.com Cc: Tony Lindgren t...@atomide.com Cc: Rob Herring rob.herr...@calxeda.com Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Stephen Warren swar...@wwwdotorg.org Cc: Ian Campbell ian.campb...@citrix.com Cc: Russell King li...@arm.linux.org.uk Cc: linux-omap@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com (cherry picked from commit 616a66351d6cd4a9bdb20fe49ee2505d9cc8a0db) Signed-off-by: Alex Shi alex@linaro.org --- arch/arm/boot/dts/omap4460.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi index 2cf227c..e21fc05 100644 --- a/arch/arm/boot/dts/omap4460.dtsi +++ b/arch/arm/boot/dts/omap4460.dtsi @@ -20,6 +20,11 @@ 92 1313000 ; clock-latency = 30; /* From legacy driver */ + + /* cooling options */ + cooling-min-level = 0; + cooling-max-level = 2; + #cooling-cells = 2; /* min followed by max */ }; }; -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/19] arm: dts: add omap5 CORE thermal data
From: Eduardo Valentin eduardo.valen...@ti.com
This patch changes a dtsi file to contain the thermal data
for CORE domain on OMAP5 and later SoCs. This data will
enable a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
(cherry picked from commit dcb5004fceeb15f0fdfc4a2b8cd68c6ad515a80b)
Signed-off-by: Alex Shi alex@linaro.org
---
arch/arm/boot/dts/omap5-core-thermal.dtsi | 28
1 file changed, 28 insertions(+)
create mode 100644 arch/arm/boot/dts/omap5-core-thermal.dtsi
diff --git a/arch/arm/boot/dts/omap5-core-thermal.dtsi
b/arch/arm/boot/dts/omap5-core-thermal.dtsi
new file mode 100644
index 000..19212ac
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-core-thermal.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for OMAP543x SoC CORE thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include dt-bindings/thermal/thermal.h
+
+core_thermal: core_thermal {
+ polling-delay-passive = 250; /* milliseconds */
+ polling-delay = 1000; /* milliseconds */
+
+ /* sensor ID */
+ thermal-sensors = bandgap 2;
+
+ trips {
+ core_crit: core_crit {
+ temperature = 125000; /* milliCelsius */
+ hysteresis = 2000; /* milliCelsius */
+ type = critical;
+ };
+ };
+};
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/19] arm: dts: add cooling properties on omap4430 cpu node
From: Eduardo Valentin eduardo.valen...@ti.com OMAP4430 devices can reach high temperatures and thus needs to have cpufreq-cooling on systems running on it. This patch adds the required cooling device properties so that cpufreq-cpu0 driver loads the cooling device. Cc: Benoît Cousson bcous...@baylibre.com Cc: Tony Lindgren t...@atomide.com Cc: Russell King li...@arm.linux.org.uk Cc: linux-omap@vger.kernel.org Cc: devicetree-disc...@lists.ozlabs.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com (cherry picked from commit 72af5e6d0c3e01655c1c1fc7c7ca94a2b663611e) Signed-off-by: Alex Shi alex@linaro.org --- arch/arm/boot/dts/omap443x.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi index cccf39a..d2deba0 100644 --- a/arch/arm/boot/dts/omap443x.dtsi +++ b/arch/arm/boot/dts/omap443x.dtsi @@ -22,6 +22,11 @@ 1008000 1375000 ; clock-latency = 30; /* From legacy driver */ + + /* cooling options */ + cooling-min-level = 0; + cooling-max-level = 3; + #cooling-cells = 2; /* min followed by max */ }; }; }; -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 8/8] x86/tlb: do flush_tlb_kernel_range by 'invlpg'
On 06/14/2012 09:26 AM, Alex Shi wrote:
On 06/14/2012 09:10 AM, Alex Shi wrote:
On 06/13/2012 10:56 PM, Andi Kleen wrote:
On Tue, Jun 12, 2012 at 05:06:45PM +0800, Alex Shi wrote:
This patch do flush_tlb_kernel_range by 'invlpg'. The performance pay
and gain was analysed in my patch (x86/flush_tlb: try flush_tlb_single
one by one in flush_tlb_range). Now we move this logical into kernel
part. The pay is multiple 'invlpg' execution cost, that is same. but
the gain(cost reducing of TLB entries refilling) is absolutely
increased.
The subtle point is whether INVLPG flushes global pages or not.
After some digging I found a sentence in the SDM that says it does.
So it may be safe.
Many thanks for your time!
What does it improve?
I just write a rough kernel modules that alloc some page arrays in kernel and
then map to vaddr by 'vmap'.
Then my macro benchmark inject a 'unmap_kernel_range' request from a sysfs
interface, and doing random memory access in user level during the time.
On my NHM EP 2P * 4 Cores * HT.
Without this patch, the memory access with 4 threads is ~12ns/time.
With this patch, the memory access with 4 threads is ~9ns/time.
With threads number increasing the benefit becomes small and nearly disappeared
after thread number up to 256.
But no any regression.
The rough user macro-benchmark and kernel module is here:
--- kernel module--
#include linux/init.h
#include linux/module.h
#include linux/moduleparam.h
#include linux/kernel.h
#include linux/spinlock.h
#include linux/slab.h
#include linux/vmalloc.h
#include linux/gfp.h
#include linux/fs.h
#include linux/mman.h
#include linux/uaccess.h
#include linux/sysfs.h
#include linux/hrtimer.h
#include linux/device.h
#include linux/cpu.h
MODULE_LICENSE(Dual BSD/GPL);
/*
* $cat Makefile
* obj-m := modvmalloc.o
*
* compile command:
* #cd linux; make /home/alexs/exec/modules/modvmalloc.ko
*/
#define NR_PAGES(4)
#define NR_BLOCKS (1024)
struct block {
struct page ** page_array;
void *vaddr;
int page_count;
};
struct block *block;
static int blocks = NR_BLOCKS;
module_param(blocks, uint, 0400);
MODULE_PARM_DESC(blocks, map unmap blocks number );
static struct page **relay_alloc_page_array(unsigned int nr_pages)
{
const size_t pa_size = NR_PAGES * sizeof(struct page *);
if (pa_size PAGE_SIZE)
return vzalloc(pa_size);
return kzalloc(pa_size, GFP_KERNEL);
}
static void relay_free_page_array(struct page **array)
{
if (is_vmalloc_addr(array))
vfree(array);
else
kfree(array);
}
static void vmap_unmap(void)
{
//purge_vmap_area_lazy();
//vm_unmap_aliases();
int i;
for (i=0; i blocks; i++)
unmap_kernel_range((unsigned long)(block-vaddr),
NR_PAGES*PAGE_SIZE);
}
// ---
long vmap_num = 0;
static ssize_t __vmap_num_store(const char *buf,
size_t count, int smt)
{
long factor = 0;
long i;
unsigned long start, stop;
if (sscanf(buf, %ld, factor) != 1)
return -EINVAL;
vmap_num = factor;
start = ktime_to_ns(ktime_get());
vmap_unmap();
stop = ktime_to_ns(ktime_get());
i = blocks;
printk(KERN_ERR vunmap %ld times cost %ld ns/time\n,
i, (stop - start)/i);
return count;
}
static ssize_t vmap_num_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
return sprintf(buf, %ld\n, vmap_num);
}
static ssize_t vmap_num_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
return __vmap_num_store(buf, count, 0);
}
DEVICE_ATTR(vmap_num, 0644,
vmap_num_show,
vmap_num_store);
int create_sysfs_vmap_num(struct device *dev)
{
return device_create_file(dev, dev_attr_vmap_num);
}
static int mapunmap_init(void){
long i,j,k;
create_sysfs_vmap_num(cpu_subsys.dev_root);
block = kmalloc(sizeof(struct block)*blocks, GFP_KERNEL);
for (k=0; k blocks; k++) {
block[k].page_count = 0;
block[k].page_array = relay_alloc_page_array(NR_PAGES);
if (!block[k].page_array)
return -1;
for (i = 0; i NR_PAGES; i++) {
block[k].page_array[i] = alloc_page(GFP_KERNEL);
if (unlikely(!block[k].page_array[i])) {
printk(KERN_ERR \talloc page error \n);
goto depopulate;
}
}
if (i!=NR_PAGES)goto depopulate;
block[k].page_count = i;
block[k].vaddr = vmap(block[k].page_array, NR_PAGES, VM_MAP,
PAGE_KERNEL
Re: [PATCH v8 8/8] x86/tlb: do flush_tlb_kernel_range by 'invlpg'
On 06/14/2012 09:10 AM, Alex Shi wrote: On 06/13/2012 10:56 PM, Andi Kleen wrote: On Tue, Jun 12, 2012 at 05:06:45PM +0800, Alex Shi wrote: This patch do flush_tlb_kernel_range by 'invlpg'. The performance pay and gain was analysed in my patch (x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range). Now we move this logical into kernel part. The pay is multiple 'invlpg' execution cost, that is same. but the gain(cost reducing of TLB entries refilling) is absolutely increased. The subtle point is whether INVLPG flushes global pages or not. After some digging I found a sentence in the SDM that says it does. So it may be safe. Many thanks for your time! What does it improve? I have not specific benchmark for this. partly due to the gain theory was proved since it is same as previous user process's page table flush. The user of tlb kernel flush in kernel is vmalloc. and Android binder IPC subsystem is using it(drivers/staging/android/binder.c) I am wondering if it can help Andriod on this? So, add cc to android-ker...@googlegroups.com Sorry, Andriod reject posting without register, so cc to linux-omap@vger.kernel.org and linux-te...@vger.kernel.org instead. -Andi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 8/8] x86/tlb: do flush_tlb_kernel_range by 'invlpg'
On 06/14/2012 09:26 AM, Alex Shi wrote: On 06/14/2012 09:10 AM, Alex Shi wrote: On 06/13/2012 10:56 PM, Andi Kleen wrote: On Tue, Jun 12, 2012 at 05:06:45PM +0800, Alex Shi wrote: This patch do flush_tlb_kernel_range by 'invlpg'. The performance pay and gain was analysed in my patch (x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range). Now we move this logical into kernel part. The pay is multiple 'invlpg' execution cost, that is same. but the gain(cost reducing of TLB entries refilling) is absolutely increased. The subtle point is whether INVLPG flushes global pages or not. After some digging I found a sentence in the SDM that says it does. So it may be safe. Many thanks for your time! What does it improve? I have not specific benchmark for this. partly due to the gain theory was proved since it is same as previous user process's page table flush. The user of tlb kernel flush in kernel is vmalloc. and Android binder IPC subsystem is using it(drivers/staging/android/binder.c) I am wondering if it can help Andriod on this? So, add cc to android-ker...@googlegroups.com Sorry, Andriod reject posting without register, so cc to linux-omap@vger.kernel.org and linux-te...@vger.kernel.org instead. Ops, forget the architecture different again This will help x86 android, not arm system. Forget above 2 mailing lists. :( -Andi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
