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: [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/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: RCU stall on panda
On 05/13/2014 11:32 PM, Tony Lindgren wrote: > * Alex Shi [140512 23:37]: >> On 05/13/2014 05:21 AM, Tony Lindgren wrote: >>> * Paul E. McKenney [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/13/2014 05:21 AM, Tony Lindgren wrote: > * Paul E. McKenney [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] [] (unwind_backtrace) from [] >>> (show_stack+0x11/0x14)^M >>> [ 95.579711] [] (show_stack) from [] >>> (dump_stack+0x75/0x88)^M >>> [ 95.587371] [] (dump_stack) from [] >>> (rcu_check_callbacks+0x353/0x79c)^M >>> [ 95.596038] [] (rcu_check_callbacks) from [] >>> (update_process_times+0x33/0x4c)^M >>> [ 95.605438] [] (update_process_times) from [] >>> (tick_sched_handle.isra.18+0x1f/0x48)^M >>> [ 95.615386] [] (tick_sched_handle.isra.18) from [] >>> (tick_sched_timer+0x3d/0x5c)^M >>> [ 95.624969] [] (tick_sched_timer) from [] >>> (__run_hrtimer+0x67/0x310)^M >>> [ 95.633544] [] (__run_hrtimer) from [] >>> (hrtimer_interrupt+0xe1/0x214)^M >>> [ 95.642211] [] (hrtimer_interrupt) from [] >>> (tick_receive_broadcast+0x1f/0x30)^M >>> [ 95.651611] [] (tick_receive_broadcast) from [] >>> (handle_IPI+0xb3/0x120)^M >>> [ 95.660461] [] (handle_IPI) from [] >>> (gic_handle_irq+0x51/0x54)^M >>> [ 95.668487] [] (gic_handle_irq) from [] >>> (__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] [] (__irq_svc) from [] >>> (cpuidle_enter_state+0xc0/0xc4)^M >>> [ 95.714477] [] (cpuidle_enter_state) from [] >>> (cpuidle_enter_state_coupled+0xe1/0x290)^M >>> [ 95.724639] [] (cpuidle_enter_state_coupled) from [] >>> (cpu_startup_entry+0x1a5/0x494)^M >>> [ 95.734680] [] (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): [] >>> cpuidle_enter_state+0xbf/0xc4^M >>> [ 95.764221] hardirqs last disabled at (128728): [] >>> __irq_svc+0x33/0x64^M >>> [ 95.772064] softirqs last enabled at (128730): [] >>> irq_enter+0x59/0x60^M >>> [ 95.779907] softirqs last disabled at (128729): [] >>> 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 >
[PATCH 10/19] arm: dts: add cooling properties on omap4430 cpu node
From: Eduardo Valentin 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" Cc: Tony Lindgren Cc: Russell King 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 (cherry picked from commit 72af5e6d0c3e01655c1c1fc7c7ca94a2b663611e) Signed-off-by: Alex Shi --- 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
[PATCH 13/19] arm: dts: add omap5 CORE thermal data
From: Eduardo Valentin
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"
Cc: Tony Lindgren
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: Russell King
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
(cherry picked from commit dcb5004fceeb15f0fdfc4a2b8cd68c6ad515a80b)
Signed-off-by: Alex Shi
---
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
+ *
+ * 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
+
+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 11/19] arm: dts: add cooling properties on omap4460 cpu node
From: Eduardo Valentin 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" Cc: Tony Lindgren Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Stephen Warren Cc: Ian Campbell Cc: Russell King 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 (cherry picked from commit 616a66351d6cd4a9bdb20fe49ee2505d9cc8a0db) Signed-off-by: Alex Shi --- 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 12/19] arm: dts: add omap5 GPU thermal data
From: Eduardo Valentin
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"
Cc: Tony Lindgren
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: Russell King
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
(cherry picked from commit 28c90169f1d5eabf503e356c76bf49a67aef4cc0)
Signed-off-by: Alex Shi
---
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
+ *
+ * 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
+
+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 09/19] arm: dts: add omap4 CPU thermal data
From: Eduardo Valentin
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"
Cc: Tony Lindgren
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: Russell King
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
(cherry picked from commit 0bbf6c54d100836db40ba020b7c9793ea3e6be0b)
Signed-off-by: Alex Shi
---
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
+ *
+ * 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
+
+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
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
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
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;
}
}
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
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
