* [GIT PULL] parisc huge page support for v4.4
@ 2015-11-22 11:51 Helge Deller
2015-11-24 15:51 ` Mikulas Patocka
0 siblings, 1 reply; 10+ messages in thread
From: Helge Deller @ 2015-11-22 11:51 UTC (permalink / raw)
To: Linus Torvalds, linux-kernel, linux-parisc, James Bottomley,
John David Anglin
Hi Linus,
please pull the latest patches for the parisc architecture for kernel v4.4 from:
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.4-2
This patchset adds Huge Page and HUGETLBFS support for parisc.
Thanks,
Helge
----------------------------------------------------------------
Helge Deller (9):
parisc: Fix wrong comment regarding first pmd entry flags
parisc: Drop definition of start_thread_som for HP-UX SOM binaries
parisc: Drop unused MADV_xxxK_PAGES flags from asm/mman.h
parisc: Add defines for Huge page support
parisc: Initialize the fault vector earlier in the boot process.
parisc: Increase initial kernel mapping to 32MB on 64bit kernel
parisc: Use long branch to do_syscall_trace_exit
parisc: Add Huge Page and HUGETLBFS support
parisc: Map kernel text and data on huge pages
arch/parisc/Kconfig | 3 +
arch/parisc/include/asm/hugetlb.h | 85 +++++++++++++++++++
arch/parisc/include/asm/page.h | 13 ++-
arch/parisc/include/asm/pgalloc.h | 2 +-
arch/parisc/include/asm/pgtable.h | 26 +++++-
arch/parisc/include/asm/processor.h | 27 ------
arch/parisc/include/uapi/asm/mman.h | 10 ---
arch/parisc/kernel/asm-offsets.c | 8 ++
arch/parisc/kernel/entry.S | 56 ++++++++-----
arch/parisc/kernel/head.S | 4 +-
arch/parisc/kernel/setup.c | 14 +++-
arch/parisc/kernel/syscall.S | 4 +-
arch/parisc/kernel/traps.c | 35 ++++----
arch/parisc/kernel/vmlinux.lds.S | 9 +-
arch/parisc/mm/Makefile | 1 +
arch/parisc/mm/hugetlbpage.c | 161 ++++++++++++++++++++++++++++++++++++
arch/parisc/mm/init.c | 40 ++++-----
17 files changed, 382 insertions(+), 116 deletions(-)
create mode 100644 arch/parisc/include/asm/hugetlb.h
create mode 100644 arch/parisc/mm/hugetlbpage.c
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [GIT PULL] parisc huge page support for v4.4 2015-11-22 11:51 [GIT PULL] parisc huge page support for v4.4 Helge Deller @ 2015-11-24 15:51 ` Mikulas Patocka 2015-11-24 15:58 ` Helge Deller 0 siblings, 1 reply; 10+ messages in thread From: Mikulas Patocka @ 2015-11-24 15:51 UTC (permalink / raw) To: Helge Deller Cc: Linus Torvalds, linux-kernel, linux-parisc, James Bottomley, John David Anglin On Sun, 22 Nov 2015, Helge Deller wrote: > Hi Linus, > > please pull the latest patches for the parisc architecture for kernel v4.4 from: > > git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.4-2 > > This patchset adds Huge Page and HUGETLBFS support for parisc. > > Thanks, > Helge > > ---------------------------------------------------------------- > Helge Deller (9): > parisc: Fix wrong comment regarding first pmd entry flags > parisc: Drop definition of start_thread_som for HP-UX SOM binaries > parisc: Drop unused MADV_xxxK_PAGES flags from asm/mman.h > parisc: Add defines for Huge page support > parisc: Initialize the fault vector earlier in the boot process. > parisc: Increase initial kernel mapping to 32MB on 64bit kernel > parisc: Use long branch to do_syscall_trace_exit > parisc: Add Huge Page and HUGETLBFS support > parisc: Map kernel text and data on huge pages > > arch/parisc/Kconfig | 3 + > arch/parisc/include/asm/hugetlb.h | 85 +++++++++++++++++++ > arch/parisc/include/asm/page.h | 13 ++- > arch/parisc/include/asm/pgalloc.h | 2 +- > arch/parisc/include/asm/pgtable.h | 26 +++++- > arch/parisc/include/asm/processor.h | 27 ------ > arch/parisc/include/uapi/asm/mman.h | 10 --- > arch/parisc/kernel/asm-offsets.c | 8 ++ > arch/parisc/kernel/entry.S | 56 ++++++++----- > arch/parisc/kernel/head.S | 4 +- > arch/parisc/kernel/setup.c | 14 +++- > arch/parisc/kernel/syscall.S | 4 +- > arch/parisc/kernel/traps.c | 35 ++++---- > arch/parisc/kernel/vmlinux.lds.S | 9 +- > arch/parisc/mm/Makefile | 1 + > arch/parisc/mm/hugetlbpage.c | 161 ++++++++++++++++++++++++++++++++++++ > arch/parisc/mm/init.c | 40 ++++----- > 17 files changed, 382 insertions(+), 116 deletions(-) > create mode 100644 arch/parisc/include/asm/hugetlb.h > create mode 100644 arch/parisc/mm/hugetlbpage.c > -- > To unsubscribe from this list: send the line "unsubscribe linux-parisc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Hi Since the kernel 4.4-rc2 I'm getting frequent boot failures on PA-RISC. When I revert this patchset, the crashes are gone. Mikulas [ 3.296666] CPU(s): 4 out of 4 PA8900 (Shortfin) at 1000.000000 MHz online [ 3.453332] Setting cache flush threshold to 65536 kB [ 3.519999] Not-handled unaligned insn 0x43ffff80 [ 3.593332] Setting TLB flush threshold to 52 kB [ 12.069998] random: nonblocking pool is initialized [ 63.869993] INFO: rcu_sched self-detected stall on CPU [ 63.869993] 0-...: (17936 ticks this GP) idle=033/140000000000001/0 softirq=11/11 fqs=8965 [ 63.869993] (t=18000 jiffies g=-293 c=-294 q=0) [ 63.869993] Task dump for CPU 0: [ 63.869993] swapper/0 R running task 0 1 0 0x00000004 [ 63.869993] Backtrace: [ 63.869993] [<00000000402149a4>] show_stack+0x14/0x20 [ 63.869993] [<000000004026807c>] sched_show_task+0x134/0x1d0 [ 63.869993] [<000000004026a96c>] dump_cpu_task+0x5c/0x78 [ 63.869993] [<000000004028cedc>] rcu_dump_cpu_stacks+0xfc/0x188 [ 63.869993] [<00000000402915b4>] rcu_check_callbacks+0x564/0x980 [ 63.869993] [<0000000040294034>] update_process_times+0x54/0xb0 [ 63.869993] [<0000000040215b2c>] timer_interrupt+0x19c/0x200 [ 63.869993] [<0000000040283de8>] handle_irq_event_percpu+0xa8/0x230 [ 63.869993] [<0000000040288efc>] handle_percpu_irq+0x9c/0xd0 [ 63.869993] [<00000000402831b8>] generic_handle_irq+0x40/0x50 [ 63.869993] [<0000000040216a00>] do_cpu_irq_mask+0x1b8/0x2a8 [ 63.869993] [<0000000040204074>] intr_return+0x0/0xc [ 63.869993] [<00000000402a69dc>] smp_call_function_many+0x33c/0x3a0 [ 63.869993] [<00000000402a6cc4>] smp_call_function+0x3c/0x50 [ 63.869993] [<00000000402a6d38>] on_each_cpu+0x30/0x78 [ 63.869993] [<0000000040213a24>] flush_cache_all+0x24/0x30 [ 63.869993] [ 63.873326] timer_interrupt(CPU 0): delayed! cycles 645CA37E rem 2BD984 next/now 1EE1C3D259/1EE197F8D5 (rs s Resetting System. [ 3.283333] CPU(s): 4 out of 4 PA8900 (Shortfin) at 1000.000000 MHz online [ 3.436666] Setting cache flush threshold to 65536 kB [ 3.506666] Not-handled unaligned insn 0x43ffff80 [ 3.506666] Setting TLB flush threshold to 176 kB [ 3.733332] SBA found Pluto 2.3 at 0xfffffffffed00000 [ 3.873332] Unaligned handler failed, ret = -1 [ 3.946666] _______________________________ [ 3.946666] < Your System ate a SPARC! Gah! > [ 3.946666] ------------------------------- [ 3.946666] \ ^__^ [ 3.946666] (__)\ )\/\ [ 3.946666] U ||----w | [ 3.946666] || || [ 4.359999] swapper/3 (pid 0): Unaligned data reference (code 28) [ 4.453332] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.0-rc2 #1 [ 4.549999] task: 000000007fca6900 ti: 000000007fcf4000 task.ti: 000000007fcf4000 [ 11.313332] [ 11.313332] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI [ 11.313332] PSW: 00001000000001001111111100000000 Not tainted ** 10665 printk messages dropped ** [ 11.333332] [<000000004020fb60>] schedule_timeout+0x158/0x1f8 ** 33399 printk messages dropped ** [ 11.396665] [<000000004020fb60>] schedule_timeout+0x158/0x1f8 ** 33416 printk messages dropped ** [ 11.469998] [<00000000402630a4>] deactivate_task+0x84/0xa0 ** 32424 printk messages dropped ** [ 11.589998] [<0000000040293f00>] msleep+0x38/0x50 ** 29540 printk messages dropped ** [ 11.709998] [<0000000040293f00>] msleep+0x38/0x50 ** 29550 printk messages dropped ** [ 11.826665] Backtrace: ** 20455 printk messages dropped ** [ 11.933332] [<0000000040104f84>] smp_callin+0x1a4/0x1c0 ** 31472 printk messages dropped ** [ 12.036665] [<0000000040293f00>] msleep+0x38/0x50 ** 29553 printk messages dropped ** [ 12.109998] [<000000004026b5a0>] dequeue_task_idle+0x40/0x60 ** 33125 printk messages dropped ** [ 12.223332] [<0000000040293f00>] msleep+0x38/0x50 ** 29573 printk messages dropped ** [ 12.326665] [<000000004026b5a0>] dequeue_task_idle+0x40/0x60 ** 33122 printk messages dropped ** [ 12.446665] [<000000004020ca64>] schedule+0x44/0xe8 ** 30208 printk messages dropped ** [ 12.553332] [<000000004027a5a4>] cpu_startup_entry+0x13c/0x300 ** 33750 printk messages dropped ** [ 12.776665] [<000000004020ca64>] schedule+0x44/0xe8 ** 30188 printk messages dropped ** [ 12.776665] [<000000004027a5a4>] cpu_startup_entry+0x13c/0x300 ** 33724 printk messages dropped ** [ 13.006665] Backtrace: ** 20455 printk messages dropped ** [ 13.006665] [<0000000040104f84>] smp_callin+0x1a4/0x1c0 ** 31454 printk messages dropped ** [ 13.126665] [<000000004021dd60>] handle_unaligned+0x908/0x958 ** 33380 printk messages dropped ** [ 13.199998] [<0000000040215350>] handle_interruption+0x338/0x910 ** 34395 printk messages dropped ** [ 13.429998] [<000000004020fc24>] schedule_timeout_uninterruptible+0x24/0x30 ** 37954 printk messages dropped ** [ 13.553331] [<000000004026b5a0>] dequeue_task_idle+0x40/0x60 ** 33004 printk messages dropped ** [ 13.553331] [<000000004020fc24>] schedule_timeout_uninterruptible+0x24/0x30 ** 37859 printk messages dropped ** [ 13.809998] [<000000004020fc24>] schedule_timeout_uninterruptible+0x24/0x30 ** 37918 printk messages dropped ** [ 13.943331] [<000000004020fb60>] schedule_timeout+0x158/0x1f8 ** 33399 printk messages dropped ** [ 13.943331] [<000000004020fb60>] schedule_timeout+0x158/0x1f8 ** 33391 printk messages dropped ** [ 14.079998] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G D 4.4.0-rc2 #1 ** 39246 printk messages dropped ** [ 14.319998] [<000000004020ca64>] schedule+0x44/0xe8 ** 30202 printk messages dropped ** [ 14.319998] [<0000000040293f00>] msleep+0x38/0x50 ** 29526 printk messages dropped ** [ 14.459998] [<0000000040104f84>] smp_callin+0x1a4/0x1c0 ** 31393 printk messages dropped ** [ 14.566665] [<0000000040214bd8>] die_if_kernel+0x220/0x298 ** 32365 printk messages dropped ** [ 14.673331] [<0000000040104f84>] smp_callin+0x1a4/0x1c0 ** 31414 printk messages dropped ** [ 14.783331] [<000000004021dd60>] handle_unaligned+0x908/0x958 ** 33411 printk messages dropped ** [ 14.899998] [<000000004026b5a0>] dequeue_task_idle+0x40/0x60 ** 33047 printk messages dropped ** [ 15.013331] [<000000004021dd60>] handle_unaligned+0x908/0x958 ** 33387 printk messages dropped ** [ 15.133331] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G D 4.4.0-rc2 #1 ** 39268 printk messages dropped ** [ 15.369998] [<000000004020fc24>] schedule_timeout_uninterruptible+0x24/0x30 ** 37924 printk messages dropped ** [ 15.509998] [<000000004023e5d0>] irq_exit+0x58/0xa0 ** 30079 printk messages dropped ** [ 15.509998] [<000000004023e5d0>] irq_exit+0x58/0xa0 ** 30107 printk messages dropped ** [ 15.646665] [<00000000402149a4>] show_stack+0x14/0x20 ** 30817 printk messages dropped ** [ 15.753331] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G D 4.4.0-rc2 #1 ** 39240 printk messages dropped ** [ 15.969998] Backtrace: ** 20424 printk messages dropped ** [ 15.969998] [<000000004020c438>] __schedule+0xe8/0x560 ** 31127 printk messages dropped ** [ 16.109998] [<000000004023e5d0>] irq_exit+0x58/0xa0 ** 30177 printk [ 16.1[<00000083331] 00402153[<00000050>] han00402153dle_inte50>] hanrruptiondle_inte+0x338/0rruptionx910 +0x338/00>] handx910 le_unali[ 16.1gned+0x983331] 08/0x958[<000000 004023e5d0>] irq_exit+0x58/0xa0 [ 16.183331] [<0000000040204074>] intr_return+0x0/0xc [ 16.183331] [<000000004027a5a4>] cpu_startup_entry+0x13c/0x300 [ 16.183331] [<0000000040104f84>] smp_callin+0x1a4/0x1c0 [ 16.183331] [ 16.183331] bad: scheduling from the idle thread! [ 16.183331] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G D 4.4.0-rc2 #1 [ 16.183331] Backtrace: [ 16.183331] [<00000000402149a4>] show_stack+0x14/0x20 [ 16.183331] [<0000000040410c18>] dump_stack+0x88/0x100 [ 16.183331] [<000000004026b5a0>] dequeue_task_idle+0x40/0x60 [ 16.183331] [<00000000402630a4>] deactivate_task+0x84/0xa0 [ 16.183331] [<000000004020c438>] __schedule+0xe8/0x560 [ 16.183331] [<000000004020ca64>] schedule+0x44/0xe8 [ 16.183331] [<000000004020fb60>] schedule_timeout+0x158/0x1f8 [ 16.183331] [<000000004020fc24>] schedule_timeout_uninterruptible+0x24/0x30 [ 16.183331] [<0000000040293f00>] msleep+0x38/0x50 [ 16.183331] [<0000000040214bd8>] die_if_kernel+0x220/0x298 [ 16.183331] [<000000004021dd60>] handle_unaligned+0x908/0x958 [ 16.183331] [<0000000040215350>] handle_interruption+0x338/0x910 [ 16.183331] [<000000004023e5d0>] irq_exit+0x58/0xa0 [ 16.183331] [<0000000040204074>] intr_return+0x0/0xc [ 16.183331] [<000000004027a5a4>] cpu_startup_entry+0x13c/0x300 [ 16.183331] [<0000000040104f84>] smp_callin+0x1a4/0x1c0 [ 16.183331] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] parisc huge page support for v4.4 2015-11-24 15:51 ` Mikulas Patocka @ 2015-11-24 15:58 ` Helge Deller 2015-11-24 16:39 ` Mikulas Patocka 0 siblings, 1 reply; 10+ messages in thread From: Helge Deller @ 2015-11-24 15:58 UTC (permalink / raw) To: Mikulas Patocka Cc: Linus Torvalds, linux-kernel, linux-parisc, James Bottomley, John David Anglin On 24.11.2015 16:51, Mikulas Patocka wrote: > On Sun, 22 Nov 2015, Helge Deller wrote: >> please pull the latest patches for the parisc architecture for kernel v4.4 from: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.4-2 >> >> This patchset adds Huge Page and HUGETLBFS support for parisc. >> >> Thanks, >> Helge >> >> ---------------------------------------------------------------- >> Helge Deller (9): >> parisc: Fix wrong comment regarding first pmd entry flags >> parisc: Drop definition of start_thread_som for HP-UX SOM binaries >> parisc: Drop unused MADV_xxxK_PAGES flags from asm/mman.h >> parisc: Add defines for Huge page support >> parisc: Initialize the fault vector earlier in the boot process. >> parisc: Increase initial kernel mapping to 32MB on 64bit kernel >> parisc: Use long branch to do_syscall_trace_exit >> parisc: Add Huge Page and HUGETLBFS support >> parisc: Map kernel text and data on huge pages >> >> arch/parisc/Kconfig | 3 + >> arch/parisc/include/asm/hugetlb.h | 85 +++++++++++++++++++ >> arch/parisc/include/asm/page.h | 13 ++- >> arch/parisc/include/asm/pgalloc.h | 2 +- >> arch/parisc/include/asm/pgtable.h | 26 +++++- >> arch/parisc/include/asm/processor.h | 27 ------ >> arch/parisc/include/uapi/asm/mman.h | 10 --- >> arch/parisc/kernel/asm-offsets.c | 8 ++ >> arch/parisc/kernel/entry.S | 56 ++++++++----- >> arch/parisc/kernel/head.S | 4 +- >> arch/parisc/kernel/setup.c | 14 +++- >> arch/parisc/kernel/syscall.S | 4 +- >> arch/parisc/kernel/traps.c | 35 ++++---- >> arch/parisc/kernel/vmlinux.lds.S | 9 +- >> arch/parisc/mm/Makefile | 1 + >> arch/parisc/mm/hugetlbpage.c | 161 ++++++++++++++++++++++++++++++++++++ >> arch/parisc/mm/init.c | 40 ++++----- >> 17 files changed, 382 insertions(+), 116 deletions(-) >> create mode 100644 arch/parisc/include/asm/hugetlb.h >> create mode 100644 arch/parisc/mm/hugetlbpage.c > > Hi > > Since the kernel 4.4-rc2 I'm getting frequent boot failures on PA-RISC. > When I revert this patchset, the crashes are gone. > [ 3.296666] CPU(s): 4 out of 4 PA8900 (Shortfin) at 1000.000000 MHz online Hi Mikulas, Yes, I've seen this as well. It affects only the PA8900 CPUs, while all PA8500-PA8700 machines seem to work fine. I do have a temporary 3-line patch to avoid the crashes which I'll push to my tree shortly. I'm still investigating why it only affects the PA8900 CPUs, but I assume it's related to the cache aliasing of those CPUs. I'll keep you updated. Helge ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] parisc huge page support for v4.4 2015-11-24 15:58 ` Helge Deller @ 2015-11-24 16:39 ` Mikulas Patocka 2015-11-24 17:00 ` Helge Deller 0 siblings, 1 reply; 10+ messages in thread From: Mikulas Patocka @ 2015-11-24 16:39 UTC (permalink / raw) To: Helge Deller Cc: Linus Torvalds, linux-kernel, linux-parisc, James Bottomley, John David Anglin On Tue, 24 Nov 2015, Helge Deller wrote: > > Hi > > > > Since the kernel 4.4-rc2 I'm getting frequent boot failures on PA-RISC. > > When I revert this patchset, the crashes are gone. > > > [ 3.296666] CPU(s): 4 out of 4 PA8900 (Shortfin) at 1000.000000 MHz online > > Hi Mikulas, > > Yes, I've seen this as well. > It affects only the PA8900 CPUs, while all PA8500-PA8700 machines seem to work fine. > I do have a temporary 3-line patch to avoid the crashes which I'll push to my tree shortly. > I'm still investigating why it only affects the PA8900 CPUs, but I assume > it's related to the cache aliasing of those CPUs. > I'll keep you updated. > > Helge The PA-RISC specification doesn't allow aliasing on non-equaivalent addresses. Can the kernel map a piece of kernel data to other virtual address? If yes, we can't use big pages to map kernel data. Mikulas ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] parisc huge page support for v4.4 2015-11-24 16:39 ` Mikulas Patocka @ 2015-11-24 17:00 ` Helge Deller 2015-11-24 18:43 ` Mikulas Patocka 0 siblings, 1 reply; 10+ messages in thread From: Helge Deller @ 2015-11-24 17:00 UTC (permalink / raw) To: Mikulas Patocka, Linus Torvalds, linux-kernel, linux-parisc, James Bottomley, John David Anglin * Mikulas Patocka <mpatocka@redhat.com>: > > > On Tue, 24 Nov 2015, Helge Deller wrote: > > > > Hi > > > > > > Since the kernel 4.4-rc2 I'm getting frequent boot failures on PA-RISC. > > > When I revert this patchset, the crashes are gone. > > > > > [ 3.296666] CPU(s): 4 out of 4 PA8900 (Shortfin) at 1000.000000 MHz online > > > > Hi Mikulas, > > > > Yes, I've seen this as well. > > It affects only the PA8900 CPUs, while all PA8500-PA8700 machines seem to work fine. > > I do have a temporary 3-line patch to avoid the crashes which I'll push to my tree shortly. > > I'm still investigating why it only affects the PA8900 CPUs, but I assume > > it's related to the cache aliasing of those CPUs. > > I'll keep you updated. > > > > Helge > > The PA-RISC specification doesn't allow aliasing on non-equaivalent > addresses. Can the kernel map a piece of kernel data to other virtual > address? If yes, we can't use big pages to map kernel data. Can you please try the two patches below? The first one disables mapping kernel text/data on huge pages on PA8800/PA8900 CPUs. Patch works for me on my Mako PA8800. Independend of my huge page patch the second patch disables the tlb flush optimization we added earlier. It seems calling flush_tlb_all() doesn't reliably flushes tlbs on all CPUs so it's better to fall back to the loop implementation. Helge diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c index 1b366c4..958b7f36 100644 --- a/arch/parisc/mm/init.c +++ b/arch/parisc/mm/init.c @@ -475,19 +475,22 @@ static void __init map_pages(unsigned long start_vaddr, pte = __mk_pte(address, pgprot); else if (parisc_text_address(vaddr)) { pte = __mk_pte(address, PAGE_KERNEL_EXEC); - if (address >= ro_start && address < kernel_end) + if (address >= ro_start && address < kernel_end + && !parisc_requires_coherency()) pte = pte_mkhuge(pte); } else #if defined(CONFIG_PARISC_PAGE_SIZE_4KB) if (address >= ro_start && address < ro_end) { pte = __mk_pte(address, PAGE_KERNEL_EXEC); - pte = pte_mkhuge(pte); + if (!parisc_requires_coherency()) + pte = pte_mkhuge(pte); } else #endif { pte = __mk_pte(address, pgprot); - if (address >= ro_start && address < kernel_end) + if (address >= ro_start && address < kernel_end + && !parisc_requires_coherency()) pte = pte_mkhuge(pte); } diff --git a/arch/parisc/kernel/cache.c b/arch/parisc/kernel/cache.c index cda6dbb..80ced95 100644 --- a/arch/parisc/kernel/cache.c +++ b/arch/parisc/kernel/cache.c @@ -445,7 +445,7 @@ int __flush_tlb_range(unsigned long sid, unsigned long start, unsigned long flags, size; size = (end - start); - if (size >= parisc_tlb_flush_threshold) { + if (0 && size >= parisc_tlb_flush_threshold) { flush_tlb_all(); return 1; } ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [GIT PULL] parisc huge page support for v4.4 2015-11-24 17:00 ` Helge Deller @ 2015-11-24 18:43 ` Mikulas Patocka 2015-12-26 12:09 ` Mikulas Patocka 0 siblings, 1 reply; 10+ messages in thread From: Mikulas Patocka @ 2015-11-24 18:43 UTC (permalink / raw) To: Helge Deller Cc: Linus Torvalds, linux-kernel, linux-parisc, James Bottomley, John David Anglin On Tue, 24 Nov 2015, Helge Deller wrote: > * Mikulas Patocka <mpatocka@redhat.com>: > > > > > > On Tue, 24 Nov 2015, Helge Deller wrote: > > > > > > Hi > > > > > > > > Since the kernel 4.4-rc2 I'm getting frequent boot failures on PA-RISC. > > > > When I revert this patchset, the crashes are gone. > > > > > > > [ 3.296666] CPU(s): 4 out of 4 PA8900 (Shortfin) at 1000.000000 MHz online > > > > > > Hi Mikulas, > > > > > > Yes, I've seen this as well. > > > It affects only the PA8900 CPUs, while all PA8500-PA8700 machines seem to work fine. > > > I do have a temporary 3-line patch to avoid the crashes which I'll push to my tree shortly. > > > I'm still investigating why it only affects the PA8900 CPUs, but I assume > > > it's related to the cache aliasing of those CPUs. > > > I'll keep you updated. > > > > > > Helge > > > > The PA-RISC specification doesn't allow aliasing on non-equaivalent > > addresses. Can the kernel map a piece of kernel data to other virtual > > address? If yes, we can't use big pages to map kernel data. > > Can you please try the two patches below? > The first one disables mapping kernel text/data on huge pages on > PA8800/PA8900 CPUs. Patch works for me on my Mako PA8800. > > Independend of my huge page patch the second patch disables the tlb > flush optimization we added earlier. It seems calling flush_tlb_all() > doesn't reliably flushes tlbs on all CPUs so it's better to fall back to > the loop implementation. > > Helge The kernel with these patches works fine so far. Mikulas ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] parisc huge page support for v4.4 2015-11-24 18:43 ` Mikulas Patocka @ 2015-12-26 12:09 ` Mikulas Patocka 2015-12-26 12:31 ` Helge Deller 0 siblings, 1 reply; 10+ messages in thread From: Mikulas Patocka @ 2015-12-26 12:09 UTC (permalink / raw) To: Helge Deller Cc: Linus Torvalds, linux-kernel, linux-parisc, James Bottomley, John David Anglin On Tue, 24 Nov 2015, Mikulas Patocka wrote: > > > On Tue, 24 Nov 2015, Helge Deller wrote: > > > * Mikulas Patocka <mpatocka@redhat.com>: > > > > > > > > > On Tue, 24 Nov 2015, Helge Deller wrote: > > > > > > > > Hi > > > > > > > > > > Since the kernel 4.4-rc2 I'm getting frequent boot failures on PA-RISC. > > > > > When I revert this patchset, the crashes are gone. > > > > > > > > > [ 3.296666] CPU(s): 4 out of 4 PA8900 (Shortfin) at 1000.000000 MHz online > > > > > > > > Hi Mikulas, > > > > > > > > Yes, I've seen this as well. > > > > It affects only the PA8900 CPUs, while all PA8500-PA8700 machines seem to work fine. > > > > I do have a temporary 3-line patch to avoid the crashes which I'll push to my tree shortly. > > > > I'm still investigating why it only affects the PA8900 CPUs, but I assume > > > > it's related to the cache aliasing of those CPUs. > > > > I'll keep you updated. > > > > > > > > Helge > > > > > > The PA-RISC specification doesn't allow aliasing on non-equaivalent > > > addresses. Can the kernel map a piece of kernel data to other virtual > > > address? If yes, we can't use big pages to map kernel data. > > > > Can you please try the two patches below? > > The first one disables mapping kernel text/data on huge pages on > > PA8800/PA8900 CPUs. Patch works for me on my Mako PA8800. > > > > Independend of my huge page patch the second patch disables the tlb > > flush optimization we added earlier. It seems calling flush_tlb_all() > > doesn't reliably flushes tlbs on all CPUs so it's better to fall back to > > the loop implementation. > > > > Helge > > The kernel with these patches works fine so far. > > Mikulas BTW. I looked at this in arch/parisc/mm/hugetlbpage.c:set_huge_pte_at "*ptep = entry;" and it seems like a bad bug. PA-RISC doesn't have atomic instructions to modify page table entries, so it takes spinlock in the TLB handler and modifies the page table entry non-atomically. If you modify the page table entry without the spinlock, you may race with TLB handler on another CPU and your modification may be lost. The comment says something about double locking on pa_tlb_lock, but pa_tlb_lock isn't held when that function is called. Mikulas ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] parisc huge page support for v4.4 2015-12-26 12:09 ` Mikulas Patocka @ 2015-12-26 12:31 ` Helge Deller 2016-01-04 21:24 ` Mikulas Patocka 0 siblings, 1 reply; 10+ messages in thread From: Helge Deller @ 2015-12-26 12:31 UTC (permalink / raw) To: Mikulas Patocka Cc: Linus Torvalds, linux-kernel, linux-parisc, James Bottomley, John David Anglin On 26.12.2015 13:09, Mikulas Patocka wrote: >> On Tue, 24 Nov 2015, Helge Deller wrote: >>> * Mikulas Patocka <mpatocka@redhat.com>: >>>> On Tue, 24 Nov 2015, Helge Deller wrote: >>>>>> Hi >>>>>> >>>>>> Since the kernel 4.4-rc2 I'm getting frequent boot failures on PA-RISC. >>>>>> When I revert this patchset, the crashes are gone. >>>>> >>>>>> [ 3.296666] CPU(s): 4 out of 4 PA8900 (Shortfin) at 1000.000000 MHz online >>>>> >>>>> Hi Mikulas, >>>>> >>>>> Yes, I've seen this as well. >>>>> It affects only the PA8900 CPUs, while all PA8500-PA8700 machines seem to work fine. >>>>> I do have a temporary 3-line patch to avoid the crashes which I'll push to my tree shortly. >>>>> I'm still investigating why it only affects the PA8900 CPUs, but I assume >>>>> it's related to the cache aliasing of those CPUs. >>>>> I'll keep you updated. >>>>> >>>>> Helge >>>> >>>> The PA-RISC specification doesn't allow aliasing on non-equaivalent >>>> addresses. Can the kernel map a piece of kernel data to other virtual >>>> address? If yes, we can't use big pages to map kernel data. >>> >>> Can you please try the two patches below? >>> The first one disables mapping kernel text/data on huge pages on >>> PA8800/PA8900 CPUs. Patch works for me on my Mako PA8800. >>> >>> Independend of my huge page patch the second patch disables the tlb >>> flush optimization we added earlier. It seems calling flush_tlb_all() >>> doesn't reliably flushes tlbs on all CPUs so it's better to fall back to >>> the loop implementation. >>> >>> Helge >> >> The kernel with these patches works fine so far. >> >> Mikulas > > BTW. I looked at this in arch/parisc/mm/hugetlbpage.c:set_huge_pte_at > "*ptep = entry;" and it seems like a bad bug. PA-RISC doesn't have atomic > instructions to modify page table entries, so it takes spinlock in the TLB > handler and modifies the page table entry non-atomically. If you modify > the page table entry without the spinlock, you may race with TLB handler > on another CPU and your modification may be lost. Right. > The comment says something about double locking on pa_tlb_lock, but > pa_tlb_lock isn't held when that function is called. I have a work-in-progress patch for that in one of my trees, e.g.: http://git.kernel.org/cgit/linux/kernel/git/deller/parisc-linux.git/commit/?h=parisc-next&id=5c76b525cbdb097401f46522b27b1eb6244f34f9 It's lightly tested though. Helge ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] parisc huge page support for v4.4 2015-12-26 12:31 ` Helge Deller @ 2016-01-04 21:24 ` Mikulas Patocka 2016-01-04 21:48 ` John David Anglin 0 siblings, 1 reply; 10+ messages in thread From: Mikulas Patocka @ 2016-01-04 21:24 UTC (permalink / raw) To: Helge Deller Cc: Linus Torvalds, linux-kernel, linux-parisc, James Bottomley, John David Anglin On Sat, 26 Dec 2015, Helge Deller wrote: > On 26.12.2015 13:09, Mikulas Patocka wrote: > > > BTW. I looked at this in arch/parisc/mm/hugetlbpage.c:set_huge_pte_at > > "*ptep = entry;" and it seems like a bad bug. PA-RISC doesn't have atomic > > instructions to modify page table entries, so it takes spinlock in the TLB > > handler and modifies the page table entry non-atomically. If you modify > > the page table entry without the spinlock, you may race with TLB handler > > on another CPU and your modification may be lost. > > Right. > > > The comment says something about double locking on pa_tlb_lock, but > > pa_tlb_lock isn't held when that function is called. > > I have a work-in-progress patch for that in one of my trees, e.g.: > http://git.kernel.org/cgit/linux/kernel/git/deller/parisc-linux.git/commit/?h=parisc-next&id=5c76b525cbdb097401f46522b27b1eb6244f34f9 > It's lightly tested though. > > Helge I tested the patch and it works OK for me so far. BTW. what happens if some kernel code takes the TLB spinlock and then TLB miss in kernel space happens? (it would attempt to lock the spinlock recursively) Is it assumed that the TLB is big enough that this can't happen? Mikulas ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] parisc huge page support for v4.4 2016-01-04 21:24 ` Mikulas Patocka @ 2016-01-04 21:48 ` John David Anglin 0 siblings, 0 replies; 10+ messages in thread From: John David Anglin @ 2016-01-04 21:48 UTC (permalink / raw) To: Mikulas Patocka, Helge Deller Cc: Linus Torvalds, linux-kernel, linux-parisc, James Bottomley On 2016-01-04 4:24 PM, Mikulas Patocka wrote: > > On Sat, 26 Dec 2015, Helge Deller wrote: > >> On 26.12.2015 13:09, Mikulas Patocka wrote: >> >>> BTW. I looked at this in arch/parisc/mm/hugetlbpage.c:set_huge_pte_at >>> "*ptep = entry;" and it seems like a bad bug. PA-RISC doesn't have atomic >>> instructions to modify page table entries, so it takes spinlock in the TLB >>> handler and modifies the page table entry non-atomically. If you modify >>> the page table entry without the spinlock, you may race with TLB handler >>> on another CPU and your modification may be lost. >> Right. >> >>> The comment says something about double locking on pa_tlb_lock, but >>> pa_tlb_lock isn't held when that function is called. >> I have a work-in-progress patch for that in one of my trees, e.g.: >> http://git.kernel.org/cgit/linux/kernel/git/deller/parisc-linux.git/commit/?h=parisc-next&id=5c76b525cbdb097401f46522b27b1eb6244f34f9 >> It's lightly tested though. >> >> Helge > I tested the patch and it works OK for me so far. > > BTW. what happens if some kernel code takes the TLB spinlock and then TLB > miss in kernel space happens? (it would attempt to lock the spinlock > recursively) Is it assumed that the TLB is big enough that this can't > happen? No. If you look at the TLB handler, you will see that locking is not done for misses in kernel space. So, this deadlock doesn't occur. Dave -- John David Anglin dave.anglin@bell.net ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-01-04 21:48 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-11-22 11:51 [GIT PULL] parisc huge page support for v4.4 Helge Deller 2015-11-24 15:51 ` Mikulas Patocka 2015-11-24 15:58 ` Helge Deller 2015-11-24 16:39 ` Mikulas Patocka 2015-11-24 17:00 ` Helge Deller 2015-11-24 18:43 ` Mikulas Patocka 2015-12-26 12:09 ` Mikulas Patocka 2015-12-26 12:31 ` Helge Deller 2016-01-04 21:24 ` Mikulas Patocka 2016-01-04 21:48 ` John David Anglin
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.