* RE: [PATCH V3 1/2] mm: move FAULT_AROUND_ORDER to arch/
From: Kirill A. Shutemov @ 2014-04-28 9:36 UTC (permalink / raw)
To: Madhavan Srinivasan
Cc: linux-arch, riel, rusty, dave.hansen, peterz, x86, linux-kernel,
Madhavan Srinivasan, linux-mm, ak, paulus, mgorman, akpm,
linuxppc-dev, mingo, kirill.shutemov
In-Reply-To: <1398675690-16186-2-git-send-email-maddy@linux.vnet.ibm.com>
Madhavan Srinivasan wrote:
> Kirill A. Shutemov with 8c6e50b029 commit introduced
> vm_ops->map_pages() for mapping easy accessible pages around
> fault address in hope to reduce number of minor page faults.
>
> This patch creates infrastructure to modify the FAULT_AROUND_ORDER
> value using mm/Kconfig. This will enable architecture maintainers
> to decide on suitable FAULT_AROUND_ORDER value based on
> performance data for that architecture. Patch also defaults
> FAULT_AROUND_ORDER Kconfig element to 4.
>
> Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
> ---
> mm/Kconfig | 8 ++++++++
> mm/memory.c | 11 ++++-------
> 2 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/mm/Kconfig b/mm/Kconfig
> index ebe5880..c7fc4f1 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -176,6 +176,14 @@ config MOVABLE_NODE
> config HAVE_BOOTMEM_INFO_NODE
> def_bool n
>
> +#
> +# Fault around order is a control knob to decide the fault around pages.
> +# Default value is set to 4 , but the arch can override it as desired.
> +#
> +config FAULT_AROUND_ORDER
> + int
> + default 4
> +
> # eventually, we can have this option just 'select SPARSEMEM'
> config MEMORY_HOTPLUG
> bool "Allow for memory hot-add"
> diff --git a/mm/memory.c b/mm/memory.c
> index d0f0bef..457436d 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3382,11 +3382,9 @@ void do_set_pte(struct vm_area_struct *vma, unsigned long address,
> update_mmu_cache(vma, address, pte);
> }
>
> -#define FAULT_AROUND_ORDER 4
> +unsigned int fault_around_order = CONFIG_FAULT_AROUND_ORDER;
>
> #ifdef CONFIG_DEBUG_FS
> -static unsigned int fault_around_order = FAULT_AROUND_ORDER;
> -
> static int fault_around_order_get(void *data, u64 *val)
> {
> *val = fault_around_order;
> @@ -3395,7 +3393,6 @@ static int fault_around_order_get(void *data, u64 *val)
>
> static int fault_around_order_set(void *data, u64 val)
> {
> - BUILD_BUG_ON((1UL << FAULT_AROUND_ORDER) > PTRS_PER_PTE);
> if (1UL << val > PTRS_PER_PTE)
> return -EINVAL;
> fault_around_order = val;
> @@ -3430,14 +3427,14 @@ static inline unsigned long fault_around_pages(void)
> {
> unsigned long nr_pages;
>
> - nr_pages = 1UL << FAULT_AROUND_ORDER;
> + nr_pages = 1UL << fault_around_order;
> BUILD_BUG_ON(nr_pages > PTRS_PER_PTE);
This BUILD_BUG_ON() doesn't make sense any more since compiler usually can't
prove anything about extern variable.
Drop it or change to VM_BUG_ON() or something.
> return nr_pages;
> }
>
> static inline unsigned long fault_around_mask(void)
> {
> - return ~((1UL << (PAGE_SHIFT + FAULT_AROUND_ORDER)) - 1);
> + return ~((1UL << (PAGE_SHIFT + fault_around_order)) - 1);
fault_around_pages() and fault_around_mask() should be moved outside of
#ifdef CONFIG_DEBUG_FS and consolidated since they are practically identical
both branches after the changes.
> }
> #endif
>
> @@ -3495,7 +3492,7 @@ static int do_read_fault(struct mm_struct *mm, struct vm_area_struct *vma,
> * if page by the offset is not ready to be mapped (cold cache or
> * something).
> */
> - if (vma->vm_ops->map_pages) {
> + if ((vma->vm_ops->map_pages) && (fault_around_order)) {
Way too many parentheses.
> pte = pte_offset_map_lock(mm, pmd, address, &ptl);
> do_fault_around(vma, address, pte, pgoff, flags);
> if (!pte_same(*pte, orig_pte))
--
Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH 2/3] powerpc, ptrace: Add new ptrace request macros for transactional memory
From: Anshuman Khandual @ 2014-04-28 10:30 UTC (permalink / raw)
To: Pedro Alves; +Cc: mikey, avagin, oleg, linux-kernel, linuxppc-dev
In-Reply-To: <535AF2E9.1000005@redhat.com>
On 04/26/2014 05:12 AM, Pedro Alves wrote:
> On 04/02/2014 08:02 AM, Anshuman Khandual wrote:
>> This patch adds following new sets of ptrace request macros for transactional
>> memory expanding the existing ptrace ABI on PowerPC.
>>
>> /* TM special purpose registers */
>> PTRACE_GETTM_SPRREGS
>> PTRACE_SETTM_SPRREGS
>>
>> /* TM checkpointed GPR registers */
>> PTRACE_GETTM_CGPRREGS
>> PTRACE_SETTM_CGPRREGS
>>
>> /* TM checkpointed FPR registers */
>> PTRACE_GETTM_CFPRREGS
>> PTRACE_SETTM_CFPRREGS
>>
>> /* TM checkpointed VMX registers */
>> PTRACE_GETTM_CVMXREGS
>> PTRACE_SETTM_CVMXREGS
>
> Urgh, we're _still_ adding specialized register specific calls?
> Why aren't these exported as new register sets, accessible through
> PTRACE_GETREGSET / PTRACE_SETREGSET? That's supposed to be the
> Modern Way to do things.
All these new register sets can be accessed through PTRACE_GETREGSET
/SETREGSET requests with the new NT_PPC_* core note types added in the
previous patch. PowerPC already has some register specific ptrace
requests, so thought of adding some new requests for transactional
memory purpose. But yes these are redundant and can be dropped.
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/powernv: reduce multi-hit of iommu_add_device()
From: Alexey Kardashevskiy @ 2014-04-28 13:35 UTC (permalink / raw)
To: Wei Yang, linuxppc-dev; +Cc: gwshan
In-Reply-To: <1398219993-6326-1-git-send-email-weiyang@linux.vnet.ibm.com>
On 04/23/2014 12:26 PM, Wei Yang wrote:
> During the EEH hotplug event, iommu_add_device() will be invoked three times
> and two of them will trigger warning or error.
>
> The three times to invoke the iommu_add_device() are:
>
> pci_device_add
> ...
> set_iommu_table_base_and_group <- 1st time, fail
> device_add
> ...
> tce_iommu_bus_notifier <- 2nd time, succees
> pcibios_add_pci_devices
> ...
> pcibios_setup_bus_devices <- 3rd time, re-attach
>
> The first time fails, since the dev->kobj->sd is not initialized. The
> dev->kobj->sd is initialized in device_add().
> The third time's warning is triggered by the re-attach of the iommu_group.
>
> After applying this patch, the error
Nack.
The patch still seems incorrect and we actually need to remove
tce_iommu_bus_notifier completely as pcibios_setup_bus_devices is called
from another notifier anyway. Could you please test it?
>
> iommu_tce: 0003:05:00.0 has not been added, ret=-14
>
> and the warning
>
> [ 204.123609] ------------[ cut here ]------------
> [ 204.123645] WARNING: at arch/powerpc/kernel/iommu.c:1125
> [ 204.123680] Modules linked in: xt_CHECKSUM nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT bnep bluetooth 6lowpan_iphc rfkill xt_conntrack ebtable_nat ebtable_broute bridge stp llc mlx4_ib ib_sa ib_mad ib_core ib_addr ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw bnx2x tg3 mlx4_core nfsd ptp mdio ses libcrc32c nfs_acl enclosure be2net pps_core shpchp lockd kvm uinput sunrpc binfmt_misc lpfc scsi_transport_fc ipr scsi_tgt
> [ 204.124356] CPU: 18 PID: 650 Comm: eehd Not tainted 3.14.0-rc5yw+ #102
> [ 204.124400] task: c0000027ed485670 ti: c0000027ed50c000 task.ti: c0000027ed50c000
> [ 204.124453] NIP: c00000000003cf80 LR: c00000000006c648 CTR: c00000000006c5c0
> [ 204.124506] REGS: c0000027ed50f440 TRAP: 0700 Not tainted (3.14.0-rc5yw+)
> [ 204.124558] MSR: 9000000000029032 <SF,HV,EE,ME,IR,DR,RI> CR: 88008084 XER: 20000000
> [ 204.124682] CFAR: c00000000006c644 SOFTE: 1
> GPR00: c00000000006c648 c0000027ed50f6c0 c000000001398380 c0000027ec260300
> GPR04: c0000027ea92c000 c00000000006ad00 c0000000016e41b0 0000000000000110
> GPR08: c0000000012cd4c0 0000000000000001 c0000027ec2602ff 0000000000000062
> GPR12: 0000000028008084 c00000000fdca200 c0000000000d1d90 c0000027ec281a80
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
> GPR24: 000000005342697b 0000000000002906 c000001fe6ac9800 c000001fe6ac9800
> GPR28: 0000000000000000 c0000000016e3a80 c0000027ea92c090 c0000027ea92c000
> [ 204.125353] NIP [c00000000003cf80] .iommu_add_device+0x30/0x1f0
> [ 204.125399] LR [c00000000006c648] .pnv_pci_ioda_dma_dev_setup+0x88/0xb0
> [ 204.125443] Call Trace:
> [ 204.125464] [c0000027ed50f6c0] [c0000027ed50f750] 0xc0000027ed50f750 (unreliable)
> [ 204.125526] [c0000027ed50f750] [c00000000006c648] .pnv_pci_ioda_dma_dev_setup+0x88/0xb0
> [ 204.125588] [c0000027ed50f7d0] [c000000000069cc8] .pnv_pci_dma_dev_setup+0x78/0x340
> [ 204.125650] [c0000027ed50f870] [c000000000044408] .pcibios_setup_device+0x88/0x2f0
> [ 204.125712] [c0000027ed50f940] [c000000000046040] .pcibios_setup_bus_devices+0x60/0xd0
> [ 204.125774] [c0000027ed50f9c0] [c000000000043acc] .pcibios_add_pci_devices+0xdc/0x1c0
> [ 204.125837] [c0000027ed50fa50] [c00000000086f970] .eeh_reset_device+0x36c/0x4f0
> [ 204.125939] [c0000027ed50fb20] [c00000000003a2d8] .eeh_handle_normal_event+0x448/0x480
> [ 204.126068] [c0000027ed50fbc0] [c00000000003a35c] .eeh_handle_event+0x4c/0x340
> [ 204.126192] [c0000027ed50fc80] [c00000000003a74c] .eeh_event_handler+0xfc/0x1b0
> [ 204.126319] [c0000027ed50fd30] [c0000000000d1ea0] .kthread+0x110/0x130
> [ 204.126430] [c0000027ed50fe30] [c00000000000a460] .ret_from_kernel_thread+0x5c/0x7c
> [ 204.126556] Instruction dump:
> [ 204.126610] 7c0802a6 fba1ffe8 fbc1fff0 fbe1fff8 f8010010 f821ff71 7c7e1b78 60000000
> [ 204.126787] 60000000 e87e0298 3143ffff 7d2a1910 <0b090000> 2fa90000 40de00c8 ebfe0218
> [ 204.126966] ---[ end trace 6e7aefd80add2973 ]---
>
> are cleared.
>
> This patch removes iommu_add_device() in pnv_pci_ioda_dma_dev_setup(), which
> revert part of the change in commit d905c5df(PPC: POWERNV: move
> iommu_add_device earlier).
>
> Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> index bc8e74e..bd3870e 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -1423,7 +1423,7 @@ static void pnv_pci_ioda_dma_dev_setup(struct pnv_phb *phb, struct pci_dev *pdev
>
> pe = &phb->ioda.pe_array[pdn->pe_number];
> WARN_ON(get_dma_ops(&pdev->dev) != &dma_iommu_ops);
> - set_iommu_table_base_and_group(&pdev->dev, pe->tce32_table);
> + set_iommu_table_base(&pdev->dev, pe->tce32_table);
> }
>
> static int pnv_pci_ioda_dma_set_mask(struct pnv_phb *phb,
>
--
Alexey Kardashevskiy
IBM OzLabs, LTC Team
e-mail: aik@au1.ibm.com
notes: Alexey Kardashevskiy/Australia/IBM
^ permalink raw reply
* [PATCH 1/2] powerpc/book3s: Improve machine check handling for unhandled errors
From: Mahesh J Salgaonkar @ 2014-04-28 14:16 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt; +Cc: Michael Neuling
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Current code does not check for unhandled/unrecovered errors and return from
interrupt if it is recoverable exception which in-turn triggers same machine
check exception in a loop causing hypervisor to be unresponsive.
This patch fixes this situation and forces hypervisor to panic for
unhandled/unrecovered errors.
This patch also fixes another issue where unrecoverable_exception routine
was called in real mode in case of unrecoverable exception (MSR_RI = 0).
This causes another exception vector 0x300 (data access) during system crash
leading to confusion while debugging cause of the system crash.
Also turn ME bit off while going down, so that when another MCE is hit during
panic path, system will checkstop and hypervisor will get restarted cleanly
by SP.
With the above fixes we now throw correct console messages (see below) while
crashing the system in case of unhandled/unrecoverable machine checks.
--------------
Severe Machine check interrupt [[Not recovered]
Initiator: CPU
Error type: UE [Instruction fetch]
Effective address: 0000000030002864
Oops: Machine check, sig: 7 [#1]
SMP NR_CPUS=2048 NUMA PowerNV
Modules linked in: bork(O) bridge stp llc kvm [last unloaded: bork]
CPU: 36 PID: 55162 Comm: bash Tainted: G O 3.14.0mce #1
task: c000002d72d022d0 ti: c000000007ec0000 task.ti: c000002d72de4000
NIP: 0000000030002864 LR: 00000000300151a4 CTR: 000000003001518c
REGS: c000000007ec3d80 TRAP: 0200 Tainted: G O (3.14.0mce)
MSR: 9000000000041002 <SF,HV,ME,RI> CR: 28222848 XER: 20000000
CFAR: 0000000030002838 DAR: d0000000004d0000 DSISR: 00000000 SOFTE: 1
GPR00: 000000003001512c 0000000031f92cb0 0000000030078af0 0000000030002864
GPR04: d0000000004d0000 0000000000000000 0000000030002864 ffffffffffffffc9
GPR08: 0000000000000024 0000000030008af0 000000000000002c c00000000150e728
GPR12: 9000000000041002 0000000031f90000 0000000010142550 0000000040000000
GPR16: 0000000010143cdc 0000000000000000 00000000101306fc 00000000101424dc
GPR20: 00000000101424e0 000000001013c6f0 0000000000000000 0000000000000000
GPR24: 0000000010143ce0 00000000100f6440 c000002d72de7e00 c000002d72860250
GPR28: c000002d72860240 c000002d72ac0038 0000000000000008 0000000000040000
NIP [0000000030002864] 0x30002864
LR [00000000300151a4] 0x300151a4
Call Trace:
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
---[ end trace 7285f0beac1e29d3 ]---
Sending IPI to other CPUs
IPI complete
OPAL V3 detected !
--------------
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/kernel/exceptions-64s.S | 40 +++++++++++++++++++++++++++++++---
1 file changed, 37 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 3afd391..e7eded1 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -1389,6 +1389,7 @@ machine_check_handle_early:
bl .save_nvgprs
addi r3,r1,STACK_FRAME_OVERHEAD
bl .machine_check_early
+ std r3,RESULT(r1) /* Save result */
ld r12,_MSR(r1)
#ifdef CONFIG_PPC_P7_NAP
/*
@@ -1443,11 +1444,33 @@ machine_check_handle_early:
*/
andi. r11,r12,MSR_RI
bne 2f
-1: addi r3,r1,STACK_FRAME_OVERHEAD
- bl .unrecoverable_exception
- b 1b
+1: mfspr r11,SPRN_SRR0
+ ld r10,PACAKBASE(r13)
+ LOAD_HANDLER(r10,unrecover_mce)
+ mtspr SPRN_SRR0,r10
+ ld r10,PACAKMSR(r13)
+ /*
+ * We are going down. But there are chances that we might get hit by
+ * another MCE during panic path and we may run into unstable state
+ * with no way out. Hence, turn ME bit off while going down, so that
+ * when another MCE is hit during panic path, system will checkstop
+ * and hypervisor will get restarted cleanly by SP.
+ */
+ li r3,MSR_ME
+ andc r10,r10,r3 /* Turn off MSR_ME */
+ mtspr SPRN_SRR1,r10
+ rfid
+ b .
2:
/*
+ * Check if we have successfully handled/recovered from error, if not
+ * then stay on emergency stack and panic.
+ */
+ ld r3,RESULT(r1) /* Load result */
+ cmpdi r3,0 /* see if we handled MCE successfully */
+
+ beq 1b /* if !handled then panic */
+ /*
* Return from MC interrupt.
* Queue up the MCE event so that we can log it later, while
* returning from kernel or opal call.
@@ -1460,6 +1483,17 @@ machine_check_handle_early:
MACHINE_CHECK_HANDLER_WINDUP
b machine_check_pSeries
+unrecover_mce:
+ /* Invoke machine_check_exception to print MCE event and panic. */
+ addi r3,r1,STACK_FRAME_OVERHEAD
+ bl .machine_check_exception
+ /*
+ * We will not reach here. Even if we did, there is no way out. Call
+ * unrecoverable_exception and die.
+ */
+1: addi r3,r1,STACK_FRAME_OVERHEAD
+ bl .unrecoverable_exception
+ b 1b
/*
* r13 points to the PACA, r9 contains the saved CR,
* r12 contain the saved SRR1, SRR0 is still ready for return
^ permalink raw reply related
* [PATCH 2/2] powerpc/book3s: Add stack overflow check in machine check handler.
From: Mahesh J Salgaonkar @ 2014-04-28 14:16 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt; +Cc: Michael Neuling
In-Reply-To: <20140428141622.5522.6901.stgit@mars>
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Currently machine check handler does not check for stack overflow for
nested machine check. If we hit another MCE while inside the machine check
handler repeatedly from same address then we get into risk of stack
overflow which can cause huge memory corruption. This patch limits the
nested MCE level to 4 and panic when we cross level 4.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/kernel/exceptions-64s.S | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index e7eded1..06774d8 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -439,9 +439,9 @@ BEGIN_FTR_SECTION
* R9 = CR
* Original R9 to R13 is saved on PACA_EXMC
*
- * Switch to mc_emergency stack and handle re-entrancy (though we
- * currently don't test for overflow). Save MCE registers srr1,
- * srr0, dar and dsisr and then set ME=1
+ * Switch to mc_emergency stack and handle re-entrancy (we limit
+ * the nested MCE upto level 4 to avoid stack overflow).
+ * Save MCE registers srr1, srr0, dar and dsisr and then set ME=1
*
* We use paca->in_mce to check whether this is the first entry or
* nested machine check. We increment paca->in_mce to track nested
@@ -464,6 +464,9 @@ BEGIN_FTR_SECTION
0: subi r1,r1,INT_FRAME_SIZE /* alloc stack frame */
addi r10,r10,1 /* increment paca->in_mce */
sth r10,PACA_IN_MCE(r13)
+ /* Limit nested MCE to level 4 to avoid stack overflow */
+ cmpwi r10,4
+ bgt 2f /* Check if we hit limit of 4 */
std r11,GPR1(r1) /* Save r1 on the stack. */
std r11,0(r1) /* make stack chain pointer */
mfspr r11,SPRN_SRR0 /* Save SRR0 */
@@ -482,10 +485,23 @@ BEGIN_FTR_SECTION
ori r11,r11,MSR_RI /* turn on RI bit */
ld r12,PACAKBASE(r13) /* get high part of &label */
LOAD_HANDLER(r12, machine_check_handle_early)
- mtspr SPRN_SRR0,r12
+1: mtspr SPRN_SRR0,r12
mtspr SPRN_SRR1,r11
rfid
b . /* prevent speculative execution */
+2:
+ /* Stack overflow. Stay on emergency stack and panic.
+ * Keep the ME bit off while panic-ing, so that if we hit
+ * another machine check we checkstop.
+ */
+ addi r1,r1,INT_FRAME_SIZE /* go back to previous stack frame */
+ ld r11,PACAKMSR(r13)
+ ld r12,PACAKBASE(r13)
+ LOAD_HANDLER(r12, unrecover_mce)
+ li r10,MSR_ME
+ andc r11,r11,r10 /* Turn off MSR_ME */
+ b 1b
+ b . /* prevent speculative execution */
END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
machine_check_pSeries:
^ permalink raw reply related
* [PATCH] powerpc/book3s: Increment the mce counter during machine_check_early call.
From: Mahesh J Salgaonkar @ 2014-04-28 14:17 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt; +Cc: Michael Neuling
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
We don't see MCE counter getting increased in /proc/interrupts which gives
false impression of no MCE occurred even when there were MCE events.
The machine check early handling was added for PowerKVM and we missed to
increment the MCE count in the early handler.
We also increment mce counters in the machine_check_exception call, but
in most cases where we handle the error hypervisor never reaches there
unless its fatal and we want to crash. Only during fatal situation we may
see double increment of mce count. We need to fix that. But for
now it always good to have some count increased instead of zero.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/kernel/traps.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 1bd7ca2..239f1cd 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -295,6 +295,8 @@ long machine_check_early(struct pt_regs *regs)
{
long handled = 0;
+ __get_cpu_var(irq_stat).mce_exceptions++;
+
if (cur_cpu_spec && cur_cpu_spec->machine_check_early)
handled = cur_cpu_spec->machine_check_early(regs);
return handled;
^ permalink raw reply related
* [PATCH] powerpc/book3s: Improve machine check delivery to guest.
From: Mahesh J Salgaonkar @ 2014-04-28 14:17 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt; +Cc: Michael Neuling
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Currently we forward MCEs to guest which have been recovered by guest.
And for unhandled errors we do not deliver the MCE to guest. It looks like
with no support of FWNMI in qemu, guest just panics whenever we deliver the
recovered MCEs to guest. Also, the existig code used to return to host for
unhandled errors which was casuing guest to hang with soft lockups inside
guest and makes it difficult to recover guest instance.
This patch now forwards all fatal MCEs to guest causing guest to crash/panic.
And, for recovered errors we just go back to normal functioning of guest
instead of returning to host. This fixes soft lockup issues in guest.
This patch also fixes an issue where guest MCE events were not logged to
host console.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/kvm/book3s_hv_ras.c | 15 +++++++--------
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 19 ++++++++++++++++---
2 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_ras.c b/arch/powerpc/kvm/book3s_hv_ras.c
index 768a9f9..3a5c568 100644
--- a/arch/powerpc/kvm/book3s_hv_ras.c
+++ b/arch/powerpc/kvm/book3s_hv_ras.c
@@ -113,10 +113,8 @@ static long kvmppc_realmode_mc_power7(struct kvm_vcpu *vcpu)
* We assume that if the condition is recovered then linux host
* will have generated an error log event that we will pick
* up and log later.
- * Don't release mce event now. In case if condition is not
- * recovered we do guest exit and go back to linux host machine
- * check handler. Hence we need make sure that current mce event
- * is available for linux host to consume.
+ * Don't release mce event now. We will queue up the event so that
+ * we can log the MCE event info on host console.
*/
if (!get_mce_event(&mce_evt, MCE_EVENT_DONTRELEASE))
goto out;
@@ -128,11 +126,12 @@ static long kvmppc_realmode_mc_power7(struct kvm_vcpu *vcpu)
out:
/*
- * If we have handled the error, then release the mce event because
- * we will be delivering machine check to guest.
+ * We are now going enter guest either through machine check
+ * interrupt (for unhandled errors) or will continue from
+ * current HSRR0 (for handled errors) in guest. Hence
+ * queue up the event so that we can log it from host console later.
*/
- if (handled)
- release_mce_event();
+ machine_check_queue_event();
return handled;
}
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index ffbb871..781205f 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -2101,14 +2101,27 @@ machine_check_realmode:
mr r3, r9 /* get vcpu pointer */
bl .kvmppc_realmode_machine_check
nop
- cmpdi r3, 0 /* continue exiting from guest? */
+ cmpdi r3, 0 /* Did we handle MCE ? */
ld r9, HSTATE_KVM_VCPU(r13)
li r12, BOOK3S_INTERRUPT_MACHINE_CHECK
- beq mc_cont
+ /*
+ * Deliver unhandled/fatal (e.g. UE) MCE errors to guest through
+ * machine check interrupt (set HSRR0 to 0x200). And for handled
+ * errors (no-fatal), just go back to guest execution with current
+ * HSRR0 instead of exiting guest. This new approach will inject
+ * machine check to guest for fatal error causing guest to crash.
+ *
+ * The old code used to return to host for unhandled errors which
+ * was causing guest to hang with soft lockups inside guest and
+ * makes it difficult to recover guest instance.
+ */
+ ld r10, VCPU_PC(r9)
+ ld r11, VCPU_MSR(r9)
+ bne 2f /* Continue guest execution. */
/* If not, deliver a machine check. SRR0/1 are already set */
li r10, BOOK3S_INTERRUPT_MACHINE_CHECK
bl kvmppc_msr_interrupt
- b fast_interrupt_c_return
+2: b fast_interrupt_c_return
/*
* Check the reason we woke from nap, and take appropriate action.
^ permalink raw reply related
* Re: [git pull] Please pull abiv2 branch
From: Philippe Bergheaud @ 2014-04-28 14:39 UTC (permalink / raw)
To: Anton Blanchard
Cc: philippe.bergheaud, mikey, amodra, rusty, rostedt, ulrich.weigand,
paulus, mjw, linuxppc-dev
In-Reply-To: <20140423124902.5be9dab0@kryten>
Anton Blanchard wrote:
> Here are the ABIv2 patches rebased against 3.15-rc2.
After recompiling 3.15-rc2 with the ABIv2 patches,
I see the following line in Modules.symvers:
0x00000000 TOC. vmlinux EXPORT_SYMBOL
Kernel will not load modules because TOC. has no CRC.
Is this expected ? Shouldn't TOC. have a CRC ?
Philippe
^ permalink raw reply
* Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support
From: Stephen Warren @ 2014-04-28 16:42 UTC (permalink / raw)
To: Russell King - ARM Linux, Anton Vorontsov, Barry Song, Ben Dooks,
Chris Ball, devicetree, Ian Campbell, Jaehoon Chung, Kumar Gala,
linux-arm-kernel, linux-doc, linux-mmc, linuxppc-dev, linux-tegra,
Mark Rutland, Michal Simek, Pawel Moll, Randy Dunlap, Rob Herring,
Sascha Hauer, Seungwon Jeon, Shawn Guo, spear-devel,
Thierry Reding, Ulf Hansson, Viresh Kumar
In-Reply-To: <20140423185534.GA26756@n2100.arm.linux.org.uk>
On 04/23/2014 12:55 PM, Russell King - ARM Linux wrote:
> All,
>
> This is where I'm at with trying to clean up the SDHCI mess, and sort out
> issues I've noticed when trying to get UHS support working on CuBoxes.
> This is my full patch set, but I recommend not applying patch 37 as there
> appears to be a hardware issue preventing it working reliably.
>
> In any case, patches 0-33 inclusive are the SDHCI clean up, based against
> v3.15-rc1. Patches 34 and 35 are Olof's Wifi support, 36 is my fix against
> those, and 38 adds the Broadcom Wifi and BT support for CuBox.
>
> The questions over how to handle these devices were never properly settled,
> so I recommend against merging patch 34 onwards. As for the rest, I'm not
> planning on any further work, so it may be a good idea for people to
> consider testing them with a view to getting them merged.
The series,
Tested-by: Stephen Warren <swarren@nvidia.com>
(On an NVIDIA Tegra "Jetson TK1" board, with the patches applied on top
of next-20140428, also with Andrew Bresticker's Tegra SDHCI patches
"mmc: tegra: disable UHS modes" and "mmc: tegra: fix reporting of base
clock frequency" applied)
^ permalink raw reply
* Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support
From: Chris Ball @ 2014-04-28 16:52 UTC (permalink / raw)
To: Stephen Warren
Cc: Mark Rutland, Ulf Hansson, linux-doc, Seungwon Jeon,
Thierry Reding, Russell King - ARM Linux, Anton Vorontsov,
Michal Simek, Jaehoon Chung, linux-arm-kernel, devicetree,
Pawel Moll, Ian Campbell, spear-devel, Rob Herring, Ben Dooks,
linux-tegra, Shawn Guo, Barry Song, Randy Dunlap, linux-mmc,
Viresh Kumar, Sascha Hauer, Kumar Gala, linuxppc-dev
In-Reply-To: <535E84FB.4080305@wwwdotorg.org>
Hi,
On Mon, Apr 28 2014, Stephen Warren wrote:
> The series,
> Tested-by: Stephen Warren <swarren@nvidia.com>
>
> (On an NVIDIA Tegra "Jetson TK1" board, with the patches applied on top
> of next-20140428, also with Andrew Bresticker's Tegra SDHCI patches
> "mmc: tegra: disable UHS modes" and "mmc: tegra: fix reporting of base
> clock frequency" applied)
Thanks very much Stephen, Russell for the series, and Ulf.
This seems like a good time to merge to mmc-next and call for testing
in linux-next -- I'm happy to merge a v2 PR when ready.
- Chris.
--
Chris Ball <http://printf.net/>
^ permalink raw reply
* [PATCH 3/3][RFC][v1] powerpc: kconfig: Increase the size of COMMAND_LINE_SIZE to 2048 from 512 for powerpc.
From: Joseph Salisbury @ 2014-04-28 21:11 UTC (permalink / raw)
To: linux-kernel, benh, paulus; +Cc: linuxppc-dev, anton
In-Reply-To: <cover.1398287636.git.joseph.salisbury@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1306677
While booting the PPC64EL kernel, the command line gets truncated to 512 characters. This is due to a limit of 512 defined for COMMAND_LINE_SIZE. It would be beneficial to have a command line longer than 512 characters, as iscsi targets and cloud-init parameters are passed through the kernel command line.
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
---
arch/powerpc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 3426bdc..becee70 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -614,7 +614,7 @@ config CMDLINE_BOOL
config COMMAND_LINE_SIZE
int "Maximum size of the command line."
- default "512"
+ default "2048"
help
This is the per architecture maximum command line size.
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3][RFC][v1] powerpc: Change the powerpc architecture to use Kconfig to set COMMAND_LINE_SIZE.
From: Joseph Salisbury @ 2014-04-28 21:11 UTC (permalink / raw)
To: linux-kernel, benh, paulus; +Cc: linuxppc-dev, anton
In-Reply-To: <cover.1398287636.git.joseph.salisbury@canonical.com>
The powerpc architecture currently uses asm-generic to set the value of COMMAND_LINE_SIZE. This change will allow the value of COMMAND_LINE_SIZE to be set specifically for powerpc without affecting other architectures that may use asm-generic.
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
---
arch/powerpc/include/asm/setup.h | 2 --
arch/powerpc/include/uapi/asm/setup.h | 1 -
2 files changed, 3 deletions(-)
delete mode 100644 arch/powerpc/include/uapi/asm/setup.h
diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index 11ba86e..c7b62c3 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -1,8 +1,6 @@
#ifndef _ASM_POWERPC_SETUP_H
#define _ASM_POWERPC_SETUP_H
-#include <uapi/asm/setup.h>
-
#ifndef __ASSEMBLY__
extern void ppc_printk_progress(char *s, unsigned short hex);
diff --git a/arch/powerpc/include/uapi/asm/setup.h b/arch/powerpc/include/uapi/asm/setup.h
deleted file mode 100644
index 552df83..0000000
--- a/arch/powerpc/include/uapi/asm/setup.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <asm-generic/setup.h>
--
1.9.1
^ permalink raw reply related
* [PATCH 0/3][RFC][v1] kconfig: powerpc: Make COMMAND_LINE_SIZE a kernel config option. Increase COMMAND_LINE_SIZE for the powerpc architecture.
From: Joseph Salisbury @ 2014-04-28 21:11 UTC (permalink / raw)
To: linux-kernel, benh, paulus; +Cc: linuxppc-dev, anton
I'm sending this out as a RFC to get feedback and see which way folks would like to go. Patch 1 of this patch set makes COMMAND_LINE_SIZE a seperate config option for each architecture. However, an alternative to that would be to create a single default size(Possibly 2048 to satisfy patchs 2 and 3 of this patch set) for COMMAND_LINE_SIZE in ~kernel/Kconfig or ~init/Kconfig and then allow the different architecures to either bump this size up or down if needed.
This set of changes focus on COMMAND_LINE_SIZE. An inital patch was created to increase the size of COMMAND_LINE_SIZE for the powerpc architecture. However, after looking at the code, it appears powerpc does not actually use the define in the ppc headers but uses the common generic default. It seems like having COMMAND_LINE_SIZE a kernel config options is a cleaner way to modify the value, instead of going through and chaning defines. This applies to all architectures and not just powerpc.
The powerpc architecture uses asm-generic to set the value of COMMAND_LINE_SIZE, which should be changed to a kernel config option.
The size of COMMAND_LINE_SIZE for powerpc should be longer than 512 characters, as iscsi targets and cloud-init parameters are passed through the kernel command line.
Joseph Salisbury (3):
kconfig: Change COMMAND_LINE_SIZE to a kernel config option, which is
now set per architecture.
powerpc: Change the powerpc architecture to use Kconfig to set
COMMAND_LINE_SIZE.
powerpc: kconfig: Increase the size of COMMAND_LINE_SIZE to 2048 from
512 for powerpc.
arch/alpha/Kconfig | 6 ++++++
arch/alpha/include/uapi/asm/setup.h | 4 +++-
arch/arc/Kconfig | 6 ++++++
arch/arc/include/asm/setup.h | 4 +++-
arch/arm/Kconfig | 6 ++++++
arch/arm/include/uapi/asm/setup.h | 4 +++-
arch/arm64/Kconfig | 6 ++++++
arch/arm64/include/uapi/asm/setup.h | 4 +++-
arch/avr32/Kconfig | 6 ++++++
arch/avr32/include/uapi/asm/setup.h | 4 +++-
arch/c6x/Kconfig | 6 ++++++
arch/c6x/include/uapi/asm/setup.h | 4 +++-
arch/cris/Kconfig | 6 ++++++
arch/cris/include/uapi/asm/setup.h | 4 +++-
arch/frv/Kconfig | 6 ++++++
arch/frv/include/uapi/asm/setup.h | 5 +++--
arch/ia64/Kconfig | 6 ++++++
arch/ia64/include/uapi/asm/setup.h | 4 +++-
arch/m32r/Kconfig | 6 ++++++
arch/m32r/include/uapi/asm/setup.h | 5 +++--
arch/m68k/Kconfig | 6 ++++++
arch/m68k/include/uapi/asm/setup.h | 4 +++-
arch/microblaze/Kconfig | 6 ++++++
arch/microblaze/include/uapi/asm/setup.h | 4 +++-
arch/mips/Kconfig | 6 ++++++
arch/mips/include/uapi/asm/setup.h | 5 +++--
arch/mn10300/Kconfig | 6 ++++++
arch/mn10300/include/uapi/asm/param.h | 4 +++-
arch/parisc/Kconfig | 6 ++++++
arch/parisc/include/uapi/asm/setup.h | 4 +++-
arch/powerpc/Kconfig | 6 ++++++
arch/powerpc/boot/ops.h | 5 ++++-
arch/powerpc/include/asm/setup.h | 2 --
arch/powerpc/include/uapi/asm/setup.h | 1 -
arch/s390/Kconfig | 6 ++++++
arch/s390/include/uapi/asm/setup.h | 4 +++-
arch/score/Kconfig | 6 ++++++
arch/score/include/uapi/asm/setup.h | 5 ++++-
arch/sparc/Kconfig | 7 +++++++
arch/sparc/include/uapi/asm/setup.h | 7 ++-----
arch/tile/Kconfig | 6 ++++++
arch/tile/include/uapi/asm/setup.h | 5 +++--
arch/um/Kconfig.um | 6 ++++++
arch/um/include/asm/setup.h | 4 +++-
arch/x86/Kconfig | 6 ++++++
arch/x86/include/asm/setup.h | 4 +++-
arch/xtensa/Kconfig | 6 ++++++
arch/xtensa/include/uapi/asm/setup.h | 4 +++-
include/uapi/asm-generic/setup.h | 2 +-
49 files changed, 210 insertions(+), 35 deletions(-)
delete mode 100644 arch/powerpc/include/uapi/asm/setup.h
--
1.9.1
^ permalink raw reply
* [PATCH 1/3][RFC][v1] kconfig: Change COMMAND_LINE_SIZE to a kernel config option, which is now set per architecture.
From: Joseph Salisbury @ 2014-04-28 21:11 UTC (permalink / raw)
To: linux-kernel, benh, paulus; +Cc: linuxppc-dev, anton
In-Reply-To: <cover.1398287636.git.joseph.salisbury@canonical.com>
Having COMMAND_LINE_SIZE a kernel config option is a cleaner way to modify the value if needed. Currently defines need to be changed within the architecture specific header files.
The default COMMAND_LINE_SIZE for asm-generic is still set by a define in include/asm-generic/setup.h.
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
---
arch/alpha/Kconfig | 6 ++++++
arch/alpha/include/uapi/asm/setup.h | 4 +++-
arch/arc/Kconfig | 6 ++++++
arch/arc/include/asm/setup.h | 4 +++-
arch/arm/Kconfig | 6 ++++++
arch/arm/include/uapi/asm/setup.h | 4 +++-
arch/arm64/Kconfig | 6 ++++++
arch/arm64/include/uapi/asm/setup.h | 4 +++-
arch/avr32/Kconfig | 6 ++++++
arch/avr32/include/uapi/asm/setup.h | 4 +++-
arch/c6x/Kconfig | 6 ++++++
arch/c6x/include/uapi/asm/setup.h | 4 +++-
arch/cris/Kconfig | 6 ++++++
arch/cris/include/uapi/asm/setup.h | 4 +++-
arch/frv/Kconfig | 6 ++++++
arch/frv/include/uapi/asm/setup.h | 5 +++--
arch/ia64/Kconfig | 6 ++++++
arch/ia64/include/uapi/asm/setup.h | 4 +++-
arch/m32r/Kconfig | 6 ++++++
arch/m32r/include/uapi/asm/setup.h | 5 +++--
arch/m68k/Kconfig | 6 ++++++
arch/m68k/include/uapi/asm/setup.h | 4 +++-
arch/microblaze/Kconfig | 6 ++++++
arch/microblaze/include/uapi/asm/setup.h | 4 +++-
arch/mips/Kconfig | 6 ++++++
arch/mips/include/uapi/asm/setup.h | 5 +++--
arch/mn10300/Kconfig | 6 ++++++
arch/mn10300/include/uapi/asm/param.h | 4 +++-
arch/parisc/Kconfig | 6 ++++++
arch/parisc/include/uapi/asm/setup.h | 4 +++-
arch/powerpc/Kconfig | 6 ++++++
arch/powerpc/boot/ops.h | 5 ++++-
arch/s390/Kconfig | 6 ++++++
arch/s390/include/uapi/asm/setup.h | 4 +++-
arch/score/Kconfig | 6 ++++++
arch/score/include/uapi/asm/setup.h | 5 ++++-
arch/sparc/Kconfig | 7 +++++++
arch/sparc/include/uapi/asm/setup.h | 7 ++-----
arch/tile/Kconfig | 6 ++++++
arch/tile/include/uapi/asm/setup.h | 5 +++--
arch/um/Kconfig.um | 6 ++++++
arch/um/include/asm/setup.h | 4 +++-
arch/x86/Kconfig | 6 ++++++
arch/x86/include/asm/setup.h | 4 +++-
arch/xtensa/Kconfig | 6 ++++++
arch/xtensa/include/uapi/asm/setup.h | 4 +++-
include/uapi/asm-generic/setup.h | 2 +-
47 files changed, 210 insertions(+), 32 deletions(-)
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index b7ff9a3..42bd2e7 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -563,6 +563,12 @@ config HAVE_DEC_LOCK
depends on SMP
default y
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line"
+ default "256"
+ help
+ This is the per architecture maximum command line size.
+
config NR_CPUS
int "Maximum number of CPUs (2-32)"
range 2 32
diff --git a/arch/alpha/include/uapi/asm/setup.h b/arch/alpha/include/uapi/asm/setup.h
index b50014b..f2956cc 100644
--- a/arch/alpha/include/uapi/asm/setup.h
+++ b/arch/alpha/include/uapi/asm/setup.h
@@ -1,7 +1,9 @@
#ifndef __ALPHA_SETUP_H
#define __ALPHA_SETUP_H
-#define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
/*
* We leave one page for the initial stack page, and one page for
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 9596b0a..b9e5351 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -141,6 +141,12 @@ config ARC_HAS_REENTRANT_IRQ_LV2
endif
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "256"
+ help
+ This is the per architecture maximum command line size.
+
config NR_CPUS
int "Maximum number of CPUs (2-4096)"
range 2 4096
diff --git a/arch/arc/include/asm/setup.h b/arch/arc/include/asm/setup.h
index e10f8ce..9708f1a 100644
--- a/arch/arc/include/asm/setup.h
+++ b/arch/arc/include/asm/setup.h
@@ -12,7 +12,9 @@
#include <linux/types.h>
#include <uapi/asm/setup.h>
-#define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
/*
* Data structure to map a ID to string
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ab438cb..d5fadfa 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1615,6 +1615,12 @@ config PAGE_OFFSET
default 0x80000000 if VMSPLIT_2G
default 0xC0000000
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "1024"
+ help
+ This is the per architecture maximum command line size.
+
config NR_CPUS
int "Maximum number of CPUs (2-32)"
range 2 32
diff --git a/arch/arm/include/uapi/asm/setup.h b/arch/arm/include/uapi/asm/setup.h
index 979ff40..9cded84 100644
--- a/arch/arm/include/uapi/asm/setup.h
+++ b/arch/arm/include/uapi/asm/setup.h
@@ -16,7 +16,9 @@
#include <linux/types.h>
-#define COMMAND_LINE_SIZE 1024
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
/* The list ends with an ATAG_NONE node. */
#define ATAG_NONE 0x00000000
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e6e4d37..528845f 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -186,6 +186,12 @@ config SCHED_SMT
MultiThreading at a cost of slightly increased overhead in some
places. If unsure say N here.
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "2048"
+ help
+ This is the per architecture maximum command line size.
+
config NR_CPUS
int "Maximum number of CPUs (2-32)"
range 2 32
diff --git a/arch/arm64/include/uapi/asm/setup.h b/arch/arm64/include/uapi/asm/setup.h
index 9cf2e46..f5ade83 100644
--- a/arch/arm64/include/uapi/asm/setup.h
+++ b/arch/arm64/include/uapi/asm/setup.h
@@ -21,6 +21,8 @@
#include <linux/types.h>
-#define COMMAND_LINE_SIZE 2048
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index b6878eb..e1ebdd6 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -233,6 +233,12 @@ config NMI_DEBUGGING
source "kernel/Kconfig.hz"
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "256"
+ help
+ This is the per architecture maximum command line size.
+
config CMDLINE
string "Default kernel command line"
default ""
diff --git a/arch/avr32/include/uapi/asm/setup.h b/arch/avr32/include/uapi/asm/setup.h
index a654df7..b78cc6d 100644
--- a/arch/avr32/include/uapi/asm/setup.h
+++ b/arch/avr32/include/uapi/asm/setup.h
@@ -11,6 +11,8 @@
#ifndef _UAPI__ASM_AVR32_SETUP_H__
#define _UAPI__ASM_AVR32_SETUP_H__
-#define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif /* _UAPI__ASM_AVR32_SETUP_H__ */
diff --git a/arch/c6x/Kconfig b/arch/c6x/Kconfig
index 77ea09b..9a91e99 100644
--- a/arch/c6x/Kconfig
+++ b/arch/c6x/Kconfig
@@ -57,6 +57,12 @@ source "kernel/Kconfig.freezer"
config CMDLINE_BOOL
bool "Default bootloader kernel arguments"
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "1024"
+ help
+ This is the per architecture maximum command line size.
+
config CMDLINE
string "Kernel command line"
depends on CMDLINE_BOOL
diff --git a/arch/c6x/include/uapi/asm/setup.h b/arch/c6x/include/uapi/asm/setup.h
index ad9ac97..73e46d3 100644
--- a/arch/c6x/include/uapi/asm/setup.h
+++ b/arch/c6x/include/uapi/asm/setup.h
@@ -1,6 +1,8 @@
#ifndef _UAPI_ASM_C6X_SETUP_H
#define _UAPI_ASM_C6X_SETUP_H
-#define COMMAND_LINE_SIZE 1024
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif /* _UAPI_ASM_C6X_SETUP_H */
diff --git a/arch/cris/Kconfig b/arch/cris/Kconfig
index 52731e2..d4dd8bc 100644
--- a/arch/cris/Kconfig
+++ b/arch/cris/Kconfig
@@ -65,6 +65,12 @@ menu "General setup"
source "fs/Kconfig.binfmt"
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "256"
+ help
+ This is the per architecture maximum command line size.
+
config ETRAX_CMDLINE
string "Kernel command line"
default "root=/dev/mtdblock3"
diff --git a/arch/cris/include/uapi/asm/setup.h b/arch/cris/include/uapi/asm/setup.h
index b907286..fbad81d 100644
--- a/arch/cris/include/uapi/asm/setup.h
+++ b/arch/cris/include/uapi/asm/setup.h
@@ -1,6 +1,8 @@
#ifndef _CRIS_SETUP_H
#define _CRIS_SETUP_H
-#define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif
diff --git a/arch/frv/Kconfig b/arch/frv/Kconfig
index 34aa193..6f5b071 100644
--- a/arch/frv/Kconfig
+++ b/arch/frv/Kconfig
@@ -54,6 +54,12 @@ config HZ
int
default 1000
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "512"
+ help
+ This is the per architecture maximum command line size.
+
source "init/Kconfig"
source "kernel/Kconfig.freezer"
diff --git a/arch/frv/include/uapi/asm/setup.h b/arch/frv/include/uapi/asm/setup.h
index fbf3fc9..c4ed2bf 100644
--- a/arch/frv/include/uapi/asm/setup.h
+++ b/arch/frv/include/uapi/asm/setup.h
@@ -12,7 +12,8 @@
#ifndef _UAPI_ASM_SETUP_H
#define _UAPI_ASM_SETUP_H
-#define COMMAND_LINE_SIZE 512
-
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif /* _UAPI_ASM_SETUP_H */
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 12c3afe..92c1754 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -352,6 +352,12 @@ config SMP
If you don't know what to do here, say N.
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "2048"
+ help
+ This is the per architecture maximum command line size.
+
config NR_CPUS
int "Maximum number of CPUs (2-4096)"
range 2 4096
diff --git a/arch/ia64/include/uapi/asm/setup.h b/arch/ia64/include/uapi/asm/setup.h
index 8d56458..ecfeea7 100644
--- a/arch/ia64/include/uapi/asm/setup.h
+++ b/arch/ia64/include/uapi/asm/setup.h
@@ -1,7 +1,9 @@
#ifndef __IA64_SETUP_H
#define __IA64_SETUP_H
-#define COMMAND_LINE_SIZE 2048
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
extern struct ia64_boot_param {
__u64 command_line; /* physical address of command line arguments */
diff --git a/arch/m32r/Kconfig b/arch/m32r/Kconfig
index 9e44bbd..72c265c 100644
--- a/arch/m32r/Kconfig
+++ b/arch/m32r/Kconfig
@@ -300,6 +300,12 @@ config CHIP_M32700_TS1
depends on (CHIP_M32700 && SMP)
default n
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "512"
+ help
+ This is the per architecture maximum command line size.
+
config NR_CPUS
int "Maximum number of CPUs (2-32)"
range 2 32
diff --git a/arch/m32r/include/uapi/asm/setup.h b/arch/m32r/include/uapi/asm/setup.h
index 96961a4..a45fbef 100644
--- a/arch/m32r/include/uapi/asm/setup.h
+++ b/arch/m32r/include/uapi/asm/setup.h
@@ -5,7 +5,8 @@
* This is set up by the setup-routine at boot-time
*/
-#define COMMAND_LINE_SIZE 512
-
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif /* _UAPI_ASM_M32R_SETUP_H */
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 87b7c75..9f68b97 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -124,6 +124,12 @@ endmenu
menu "Kernel Features"
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "256"
+ help
+ This is the per architecture maximum command line size.
+
if COLDFIRE
source "kernel/Kconfig.preempt"
endif
diff --git a/arch/m68k/include/uapi/asm/setup.h b/arch/m68k/include/uapi/asm/setup.h
index 6a6dc63..a96470e 100644
--- a/arch/m68k/include/uapi/asm/setup.h
+++ b/arch/m68k/include/uapi/asm/setup.h
@@ -11,6 +11,8 @@
#ifndef _UAPI_M68K_SETUP_H
#define _UAPI_M68K_SETUP_H
-#define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif /* _UAPI_M68K_SETUP_H */
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 9ae0854..fa409d6 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -91,6 +91,12 @@ comment "Boot options"
config CMDLINE_BOOL
bool "Default bootloader kernel arguments"
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "256"
+ help
+ This is the per architecture maximum command line size.
+
config CMDLINE
string "Default kernel command string"
depends on CMDLINE_BOOL
diff --git a/arch/microblaze/include/uapi/asm/setup.h b/arch/microblaze/include/uapi/asm/setup.h
index 76bc2ac..5992d0b 100644
--- a/arch/microblaze/include/uapi/asm/setup.h
+++ b/arch/microblaze/include/uapi/asm/setup.h
@@ -11,7 +11,9 @@
#ifndef _UAPI_ASM_MICROBLAZE_SETUP_H
#define _UAPI_ASM_MICROBLAZE_SETUP_H
-#define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
# ifndef __ASSEMBLY__
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 5cd695f..1200836 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2247,6 +2247,12 @@ config HW_PERF_EVENTS
source "mm/Kconfig"
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "4096"
+ help
+ This is the per architecture maximum command line size.
+
config SMP
bool "Multi-Processing support"
depends on SYS_SUPPORTS_SMP
diff --git a/arch/mips/include/uapi/asm/setup.h b/arch/mips/include/uapi/asm/setup.h
index 93f237b..323902a 100644
--- a/arch/mips/include/uapi/asm/setup.h
+++ b/arch/mips/include/uapi/asm/setup.h
@@ -1,7 +1,8 @@
#ifndef _UAPI_MIPS_SETUP_H
#define _UAPI_MIPS_SETUP_H
-#define COMMAND_LINE_SIZE 4096
-
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif /* _UAPI_MIPS_SETUP_H */
diff --git a/arch/mn10300/Kconfig b/arch/mn10300/Kconfig
index a648de1..4a940bc 100644
--- a/arch/mn10300/Kconfig
+++ b/arch/mn10300/Kconfig
@@ -199,6 +199,12 @@ config SMP
If you don't know what to do here, say N.
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "256"
+ help
+ This is the per architecture maximum command line size.
+
config NR_CPUS
int
depends on SMP
diff --git a/arch/mn10300/include/uapi/asm/param.h b/arch/mn10300/include/uapi/asm/param.h
index 02a0ca6..b632f88 100644
--- a/arch/mn10300/include/uapi/asm/param.h
+++ b/arch/mn10300/include/uapi/asm/param.h
@@ -13,6 +13,8 @@
#include <asm-generic/param.h>
-#define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif /* _ASM_PARAM_H */
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 1faefed..633ab34 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -295,6 +295,12 @@ config HPUX
bool "Support for HP-UX binaries"
depends on !64BIT
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "1024"
+ help
+ This is the per architecture maximum command line size.
+
config NR_CPUS
int "Maximum number of CPUs (2-32)"
range 2 32
diff --git a/arch/parisc/include/uapi/asm/setup.h b/arch/parisc/include/uapi/asm/setup.h
index 7da2e5b..c70453f 100644
--- a/arch/parisc/include/uapi/asm/setup.h
+++ b/arch/parisc/include/uapi/asm/setup.h
@@ -1,6 +1,8 @@
#ifndef _PARISC_SETUP_H
#define _PARISC_SETUP_H
-#define COMMAND_LINE_SIZE 1024
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif /* _PARISC_SETUP_H */
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e099899..3426bdc 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -612,6 +612,12 @@ config PPC_DENORMALISATION
config CMDLINE_BOOL
bool "Default bootloader kernel arguments"
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "512"
+ help
+ This is the per architecture maximum command line size.
+
config CMDLINE
string "Initial kernel command string"
depends on CMDLINE_BOOL
diff --git a/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
index b3218ce..8a91edb 100644
--- a/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -15,7 +15,10 @@
#include "types.h"
#include "string.h"
-#define COMMAND_LINE_SIZE 512
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
+
#define MAX_PATH_LEN 256
#define MAX_PROP_LEN 256 /* What should this be? */
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index d68fe34..01cfcbb 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -348,6 +348,12 @@ config SMP
Even if you don't know what to do here, say Y.
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "4096"
+ help
+ This is the per architecture maximum command line size.
+
config NR_CPUS
int "Maximum number of CPUs (2-256)"
range 2 256
diff --git a/arch/s390/include/uapi/asm/setup.h b/arch/s390/include/uapi/asm/setup.h
index 5a637e3..23e51e1 100644
--- a/arch/s390/include/uapi/asm/setup.h
+++ b/arch/s390/include/uapi/asm/setup.h
@@ -6,7 +6,9 @@
#ifndef _UAPI_ASM_S390_SETUP_H
#define _UAPI_ASM_S390_SETUP_H
-#define COMMAND_LINE_SIZE 4096
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#define ARCH_COMMAND_LINE_SIZE 896
diff --git a/arch/score/Kconfig b/arch/score/Kconfig
index 4ac8cae..63de4bd 100644
--- a/arch/score/Kconfig
+++ b/arch/score/Kconfig
@@ -58,6 +58,12 @@ config 32BIT
config ARCH_FLATMEM_ENABLE
def_bool y
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "256"
+ help
+ This is the per architecture maximum command line size.
+
source "mm/Kconfig"
config MEMORY_START
diff --git a/arch/score/include/uapi/asm/setup.h b/arch/score/include/uapi/asm/setup.h
index ab9dbdb..aa59951 100644
--- a/arch/score/include/uapi/asm/setup.h
+++ b/arch/score/include/uapi/asm/setup.h
@@ -1,7 +1,10 @@
#ifndef _UAPI_ASM_SCORE_SETUP_H
#define _UAPI_ASM_SCORE_SETUP_H
-#define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
+
#define MEMORY_START 0
#define MEMORY_SIZE 0x2000000
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 29f2e98..148114d 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -329,6 +329,13 @@ config CMDLINE_BOOL
bool "Default bootloader kernel arguments"
depends on SPARC64
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "256" if SPARC32
+ default "2048" if SPARC64
+ help
+ This is the per architecture maximum command line size.
+
config CMDLINE
string "Initial kernel command string"
depends on CMDLINE_BOOL
diff --git a/arch/sparc/include/uapi/asm/setup.h b/arch/sparc/include/uapi/asm/setup.h
index 5337684..bcf105b 100644
--- a/arch/sparc/include/uapi/asm/setup.h
+++ b/arch/sparc/include/uapi/asm/setup.h
@@ -5,11 +5,8 @@
#ifndef _UAPI_SPARC_SETUP_H
#define _UAPI_SPARC_SETUP_H
-#if defined(__sparc__) && defined(__arch64__)
-# define COMMAND_LINE_SIZE 2048
-#else
-# define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
#endif
-
#endif /* _UAPI_SPARC_SETUP_H */
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 85258ca..6aa6d6a 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -336,6 +336,12 @@ config CMDLINE_BOOL
Systems with fully functional boot loaders (e.g. mboot, or
if booting over PCI) should leave this option set to 'N'.
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "2048"
+ help
+ This is the per architecture maximum command line size.
+
config CMDLINE
string "Built-in kernel command string"
depends on CMDLINE_BOOL
diff --git a/arch/tile/include/uapi/asm/setup.h b/arch/tile/include/uapi/asm/setup.h
index e6f7da2..7e1e7dd 100644
--- a/arch/tile/include/uapi/asm/setup.h
+++ b/arch/tile/include/uapi/asm/setup.h
@@ -15,7 +15,8 @@
#ifndef _UAPI_ASM_TILE_SETUP_H
#define _UAPI_ASM_TILE_SETUP_H
-#define COMMAND_LINE_SIZE 2048
-
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif /* _UAPI_ASM_TILE_SETUP_H */
diff --git a/arch/um/Kconfig.um b/arch/um/Kconfig.um
index a7520c9..c0af3f9 100644
--- a/arch/um/Kconfig.um
+++ b/arch/um/Kconfig.um
@@ -119,6 +119,12 @@ config SMP
If you don't know what to do, say N.
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "4096"
+ help
+ This is the per architecture maximum command line size.
+
config NR_CPUS
int "Maximum number of CPUs (2-32)"
range 2 32
diff --git a/arch/um/include/asm/setup.h b/arch/um/include/asm/setup.h
index 99f0863..ec3c951 100644
--- a/arch/um/include/asm/setup.h
+++ b/arch/um/include/asm/setup.h
@@ -5,6 +5,8 @@
* command line, so this choice is ok.
*/
-#define COMMAND_LINE_SIZE 4096
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#endif /* SETUP_H_INCLUDED */
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 25d2c6f..67a70ae 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1826,6 +1826,12 @@ config CMDLINE_BOOL
Systems with fully functional boot loaders (i.e. non-embedded)
should leave this option set to 'N'.
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "2048"
+ help
+ This is the per architecture maximum command line size.
+
config CMDLINE
string "Built-in kernel command string"
depends on CMDLINE_BOOL
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index 9264f04..0ab46ee 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -3,7 +3,9 @@
#include <uapi/asm/setup.h>
-#define COMMAND_LINE_SIZE 2048
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
#include <linux/linkage.h>
diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
index 02d6d29..00874f8 100644
--- a/arch/xtensa/Kconfig
+++ b/arch/xtensa/Kconfig
@@ -266,6 +266,12 @@ config GENERIC_CALIBRATE_DELAY
config CMDLINE_BOOL
bool "Default bootloader kernel arguments"
+config COMMAND_LINE_SIZE
+ int "Maximum size of the command line."
+ default "256"
+ help
+ This is the per architecture maximum command line size.
+
config CMDLINE
string "Initial kernel command string"
depends on CMDLINE_BOOL
diff --git a/arch/xtensa/include/uapi/asm/setup.h b/arch/xtensa/include/uapi/asm/setup.h
index 9fa8ad9..c320d8e 100644
--- a/arch/xtensa/include/uapi/asm/setup.h
+++ b/arch/xtensa/include/uapi/asm/setup.h
@@ -11,7 +11,9 @@
#ifndef _XTENSA_SETUP_H
#define _XTENSA_SETUP_H
-#define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
+#endif
extern void set_except_vector(int n, void *addr);
diff --git a/include/uapi/asm-generic/setup.h b/include/uapi/asm-generic/setup.h
index 6fc26a5..0ec13fc 100644
--- a/include/uapi/asm-generic/setup.h
+++ b/include/uapi/asm-generic/setup.h
@@ -1,6 +1,6 @@
#ifndef __ASM_GENERIC_SETUP_H
#define __ASM_GENERIC_SETUP_H
-#define COMMAND_LINE_SIZE 512
+#define COMMAND_LINE_SIZE 512
#endif /* __ASM_GENERIC_SETUP_H */
--
1.9.1
^ permalink raw reply related
* Re: [git pull] Please pull abiv2 branch
From: Alan Modra @ 2014-04-28 23:46 UTC (permalink / raw)
To: Philippe Bergheaud
Cc: philippe.bergheaud, mikey, rusty, rostedt, ulrich.weigand, paulus,
Anton Blanchard, mjw, linuxppc-dev
In-Reply-To: <535E6804.5050508@linux.vnet.ibm.com>
On Mon, Apr 28, 2014 at 04:39:00PM +0200, Philippe Bergheaud wrote:
> Kernel will not load modules because TOC. has no CRC.
> Is this expected ? Shouldn't TOC. have a CRC ?
TOC. is really .TOC. (The kernel build process strips off a leading
dot from symbol names.) .TOC. is a special symbol giving the toc
base, so no, it shouldn't have a CRC.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* [PATCH 1/1] powerpc: crtsaveres.o needed only when -Os flag is enabled
From: Ram Pai @ 2014-04-29 0:05 UTC (permalink / raw)
To: benh, paulus; +Cc: Ram Pai, linuxppc-dev, hartb, anton, tony
powerpc: crtsaveres.o needed only when -Os flag is enabled
Currently on powerpc arch, out-of-tree module fails to build without
crtsaveres.o, even when the module has no dependency on the symbols
provided by the file; when built without the -Os flag.
BTW: '-Os' flag is enabled when CONFIG_CC_OPTIMIZE_FOR_SIZE is
configured.
This patch fixes that problem.
Signed-off-by: Ram Pai <linuxram@us.ibm.com>
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 4c0cedf..cf12f38 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -157,7 +157,10 @@ CPP = $(CC) -E $(KBUILD_CFLAGS)
CHECKFLAGS += -m$(CONFIG_WORD_SIZE) -D__powerpc__ -D__powerpc$(CONFIG_WORD_SIZE)__
+ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
KBUILD_LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
+endif
+
# No AltiVec or VSX instructions when building kernel
KBUILD_CFLAGS += $(call cc-option,-mno-altivec)
^ permalink raw reply related
* Re: [git pull] Please pull abiv2 branch
From: Rusty Russell @ 2014-04-29 0:33 UTC (permalink / raw)
To: Philippe Bergheaud, Anton Blanchard
Cc: philippe.bergheaud, mikey, amodra, rostedt, ulrich.weigand, mjw,
paulus, linuxppc-dev
In-Reply-To: <535E6804.5050508@linux.vnet.ibm.com>
Philippe Bergheaud <felix@linux.vnet.ibm.com> writes:
> Anton Blanchard wrote:
>> Here are the ABIv2 patches rebased against 3.15-rc2.
>
> After recompiling 3.15-rc2 with the ABIv2 patches,
> I see the following line in Modules.symvers:
>
> 0x00000000 TOC. vmlinux EXPORT_SYMBOL
>
> Kernel will not load modules because TOC. has no CRC.
> Is this expected ? Shouldn't TOC. have a CRC ?
What happens when you try to load a module? It should work...
Cheers,
Rusty.
^ permalink raw reply
* [PATCH] powerpc/fsl-rio: Fix fsl_rio_setup error paths and use-after-unmap
From: Scott Wood @ 2014-04-29 1:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, Liu Gang
Several of the error paths from fsl_rio_setup are missing error
messages.
Worse, fsl_rio_setup initializes several global pointers and does not
NULL them out after freeing/unmapping on error. This caused
fsl_rio_mcheck_exception() to crash when accessing rio_regs_win which
was non-NULL but had been unmapped.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Cc: Liu Gang <Gang.Liu@freescale.com>
---
Liu Gang, are you sure all of these error conditions are fatal? Why
does the rio driver fail if rmu is not present (e.g. on t4240)?
---
arch/powerpc/sysdev/fsl_rio.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index cf2b084..c04b718 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -391,8 +391,10 @@ int fsl_rio_setup(struct platform_device *dev)
ops->get_inb_message = fsl_get_inb_message;
rmu_node = of_parse_phandle(dev->dev.of_node, "fsl,srio-rmu-handle", 0);
- if (!rmu_node)
+ if (!rmu_node) {
+ dev_err(&dev->dev, "No valid fsl,srio-rmu-handle property\n");
goto err_rmu;
+ }
rc = of_address_to_resource(rmu_node, 0, &rmu_regs);
if (rc) {
dev_err(&dev->dev, "Can't get %s property 'reg'\n",
@@ -413,6 +415,7 @@ int fsl_rio_setup(struct platform_device *dev)
/*set up doobell node*/
np = of_find_compatible_node(NULL, NULL, "fsl,srio-dbell-unit");
if (!np) {
+ dev_err(&dev->dev, "No fsl,srio-dbell-unit node\n");
rc = -ENODEV;
goto err_dbell;
}
@@ -441,6 +444,7 @@ int fsl_rio_setup(struct platform_device *dev)
/*set up port write node*/
np = of_find_compatible_node(NULL, NULL, "fsl,srio-port-write-unit");
if (!np) {
+ dev_err(&dev->dev, "No fsl,srio-port-write-unit node\n");
rc = -ENODEV;
goto err_pw;
}
@@ -633,14 +637,18 @@ int fsl_rio_setup(struct platform_device *dev)
return 0;
err:
kfree(pw);
+ pw = NULL;
err_pw:
kfree(dbell);
+ dbell = NULL;
err_dbell:
iounmap(rmu_regs_win);
+ rmu_regs_win = NULL;
err_rmu:
kfree(ops);
err_ops:
iounmap(rio_regs_win);
+ rio_regs_win = NULL;
err_rio_regs:
return rc;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH V3 2/2] powerpc/pseries: init fault_around_order for pseries
From: Rusty Russell @ 2014-04-29 2:18 UTC (permalink / raw)
To: Madhavan Srinivasan, linux-kernel, linuxppc-dev, linux-mm,
linux-arch, x86
Cc: riel, ak, peterz, dave.hansen, Madhavan Srinivasan, paulus,
mgorman, akpm, mingo, kirill.shutemov
In-Reply-To: <1398675690-16186-3-git-send-email-maddy@linux.vnet.ibm.com>
Madhavan Srinivasan <maddy@linux.vnet.ibm.com> writes:
> diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
> index 2db8cc6..c87e6b6 100644
> --- a/arch/powerpc/platforms/pseries/setup.c
> +++ b/arch/powerpc/platforms/pseries/setup.c
> @@ -74,6 +74,8 @@ int CMO_SecPSP = -1;
> unsigned long CMO_PageSize = (ASM_CONST(1) << IOMMU_PAGE_SHIFT_4K);
> EXPORT_SYMBOL(CMO_PageSize);
>
> +extern unsigned int fault_around_order;
> +
It's considered bad form to do this. Put the declaration in linux/mm.h.
Thanks,
Rusty.
PS. But we're getting there! :)
^ permalink raw reply
* Re: [PATCH v2 6/6] powerpc/perf/hv-24x7: catalog version number is be64, not be32
From: Michael Ellerman @ 2014-04-29 3:12 UTC (permalink / raw)
To: Cody P Schafer; +Cc: David.Laight, Linux PPC, LKML, Anton Blanchard
In-Reply-To: <535DE027.5050700@linux.vnet.ibm.com>
On Sun, 2014-04-27 at 21:59 -0700, Cody P Schafer wrote:
> On 04/27/2014 09:47 PM, Benjamin Herrenschmidt wrote:
> > On Tue, 2014-04-15 at 10:10 -0700, Cody P Schafer wrote:
> >> The catalog version number was changed from a be32 (with proceeding
> >> 32bits of padding) to a be64, update the code to treat it as a be64
> >>
> >> Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
> >> --
> >
> > Have you tested this ?
> >
> > It doesn't build for me:
> >
> > arch/powerpc/perf/hv-24x7.c: In function 'catalog_read':
> > arch/powerpc/perf/hv-24x7.c:223:3: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint64_t' [-Werror=format]
> > cc1: all warnings being treated as errors
>
> I have, and I wasn't initially sure how I managed to miss that
> warning-as-error. On examination: My config (for some reason) has
> CONFIG_PPC_DISABLE_WERROR=y set (probably because it's a variation of a
> distro config).
Please test build with ppc64_defconfig at least.
cheers
^ permalink raw reply
* RE: [PATCH] powerpc/fsl-rio: Fix fsl_rio_setup error paths and use-after-unmap
From: Gang.Liu @ 2014-04-29 4:04 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1398735103-16513-1-git-send-email-scottwood@freescale.com>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, April 29, 2014 9:32 AM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Wood Scott-B07421; Liu Gang-B34182
> Subject: [PATCH] powerpc/fsl-rio: Fix fsl_rio_setup error paths and use-
> after-unmap
>=20
> Several of the error paths from fsl_rio_setup are missing error messages.
>=20
> Worse, fsl_rio_setup initializes several global pointers and does not
> NULL them out after freeing/unmapping on error. This caused
> fsl_rio_mcheck_exception() to crash when accessing rio_regs_win which was
> non-NULL but had been unmapped.
>=20
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> Cc: Liu Gang <Gang.Liu@freescale.com>
> ---
> Liu Gang, are you sure all of these error conditions are fatal? Why does
> the rio driver fail if rmu is not present (e.g. on t4240)?
Hi Scott, I think the errors you modified in the patch are serious and shou=
ld
be fixed. Thanks very much!
And in fact, the rio driver can be used just for the submodule of the SRIO:=
RMU.
It should be used with arch/powerpc/sysdev/fsl_rmu.c and there should have =
the
RMU module.
The fsl_rio.c implements some basic and needed works to support the RMU run=
ning well.
In addition, could you please help to apply the following patch:
http://patchwork.ozlabs.org/patch/337810/
Thanks!
Liu Gang =20
> ---
> arch/powerpc/sysdev/fsl_rio.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/powernv: reduce multi-hit of iommu_add_device()
From: Wei Yang @ 2014-04-29 6:49 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: linuxppc-dev, gwshan
In-Reply-To: <535E5924.8040503@au1.ibm.com>
On Mon, Apr 28, 2014 at 11:35:32PM +1000, Alexey Kardashevskiy wrote:
>On 04/23/2014 12:26 PM, Wei Yang wrote:
>> During the EEH hotplug event, iommu_add_device() will be invoked three times
>> and two of them will trigger warning or error.
>>
>> The three times to invoke the iommu_add_device() are:
>>
>> pci_device_add
>> ...
>> set_iommu_table_base_and_group <- 1st time, fail
>> device_add
>> ...
>> tce_iommu_bus_notifier <- 2nd time, succees
>> pcibios_add_pci_devices
>> ...
>> pcibios_setup_bus_devices <- 3rd time, re-attach
>>
>> The first time fails, since the dev->kobj->sd is not initialized. The
>> dev->kobj->sd is initialized in device_add().
>> The third time's warning is triggered by the re-attach of the iommu_group.
>>
>> After applying this patch, the error
>
>Nack.
>
>The patch still seems incorrect and we actually need to remove
>tce_iommu_bus_notifier completely as pcibios_setup_bus_devices is called
>from another notifier anyway. Could you please test it?
>
>
Hi, Alexey,
Nice to see your comment. Let me show what I got fist.
Generally, when kernel enumerate on the pci device, following functions will
be invoked.
pci_device_add
pcibios_setup_bus_device
...
set_iommu_table_base_and_group
device_add
...
tce_iommu_bus_notifier
pcibios_fixp_bus
pcibios_add_pci_devices
...
pcibios_setup_bus_devices
>From the call flow, we see for a normall pci device, the
pcibios_setup_bus_device() will be invoked twice.
At the bootup time, none of them succeed to setup the dma, since the PE is not
assigned or the tbl is not set. The iommu tbl and group is setup in
pnv_pci_ioda_setup_DMA().
This call flow maintains the same when EEH error happens on Bus PE, while the
behavior is a little different.
pci_device_add
pcibios_setup_bus_device
...
set_iommu_table_base_and_group <- fail, kobj->sd is not initialized
device_add
...
tce_iommu_bus_notifier <- succeed
pcibios_fixp_bus
pcibios_add_pci_devices
...
pcibios_setup_bus_devices <- warning, re-attach
While this call flow will change a little on a VF. For a VF,
pcibios_fixp_bus() will not be invoked. Current behavior is this.
pci_device_add
pcibios_setup_bus_device
...
set_iommu_table_base_and_group <- fail, kobj->sd is not initialized
device_add
...
tce_iommu_bus_notifier <- succeed
And if an EEH error happens just on a VF, I believe the same call flow should
go for recovery. (This is not set down, still under discussion with Gavin.)
My conclusion is:
1. remove the tce_iommu_bus_notifier completely will make the VF not work.
So I choose to revert the code and attach make the iommu group attachment
just happens in one place.
BTW, I know my patch is not a perfect one. For a PF, the tbl will still be set
twice. I am not sure why we need to invoke pcibios_setup_device() twice on a
PF, maybe some platform need to fixup some thing after the pci_bus is added.
So I don't remove one of them to solve the problem.
If you have a better idea, I am glad to take it.
--
Richard Yang
Help you, Help me
^ permalink raw reply
* Re: [PATCH 0/3] Add new ptrace request macros on PowerPC
From: Anshuman Khandual @ 2014-04-29 7:00 UTC (permalink / raw)
To: Anshuman Khandual; +Cc: mikey, avagin, linux-kernel, oleg, linuxppc-dev, roland
In-Reply-To: <533BD922.4070009@linux.vnet.ibm.com>
On 04/02/2014 03:02 PM, Anshuman Khandual wrote:
> On 04/02/2014 12:32 PM, Anshuman Khandual wrote:
>> This patch series adds new ELF note sections which are used to
>> create new ptrace request macros for various transactional memory and
>> miscellaneous registers on PowerPC. Please find the test case exploiting
>> the new ptrace request macros and it's results on a POWER8 system.
>>
>> RFC: https://lkml.org/lkml/2014/4/1/292
>>
>> ============================== Results ==============================
>> -------TM specific SPR------
>> TM TFHAR: 100009dc
>> TM TEXASR: de000001ac000001
>> TM TFIAR: c00000000003f386
>> TM CH ORIG_MSR: 900000050000f032
>> TM CH TAR: 6
>> TM CH PPR: c000000000000
>> TM CH DSCR: 1
>> -------TM checkpointed GPR-----
>> TM CH GPR[0]: 1000097c
>> TM CH GPR[1]: 5
>> TM CH GPR[2]: 6
>> TM CH GPR[7]: 1
>> TM CH NIP: 100009dc
>> TM CH LINK: 1000097c
>> TM CH CCR: 22000422
>> -------TM running GPR-----
>> TM RN GPR[0]: 1000097c
>> TM RN GPR[1]: 7
>> TM RN GPR[2]: 8
>> TM RN GPR[7]: 5
>> TM RN NIP: 100009fc
>> TM RN LINK: 1000097c
>> TM RN CCR: 2000422
>> -------TM running FPR-----
>> TM RN FPR[0]: 1002d3a3780
>> TM RN FPR[1]: 7
>> TM RN FPR[2]: 8
>> TM RN FPSCR: 0
>> -------TM checkpointed FPR-----
>> TM CH FPR[0]: 1002d3a3780
>> TM CH FPR[1]: 5
>> TM CH FPR[2]: 6
>> TM CH FPSCR: 0
>> -------Running miscellaneous registers-------
> TM RN DSCR: 0
>
> There is a problem in here which I forgot to mention. The running DSCR value
> comes from thread->dscr component of the target process. While we are inside the
> transaction (which is the case here as we are stuck at "b ." instruction and
> have not reached TEND) thread->dscr should have the running value of the DSCR
> register at that point of time. Here we expect the DSCR value to be 5 instead
> of 0 as shown in the output above. During the tests when I moved the "b ." after
> TEND, the thread->dscr gets the value of 5 while all check pointed reg values are
> thrown away. I believe there is some problem in the way thread->dscr context
> is saved away inside the TM section. Will look into this problem further and
> keep informed.
Reason behind this inconsistent DSCR register value is because of the following commit
where the kernel reverts the DSCR register into a default value to avoid running with
the user set value for a long time, thus preventing any potential performance degradation.
Same reason applies to the PPR register as well. So its not a problem but an expected
behaviour.
commit e9bdc3d6143d1c4b8d8ce5231fc958268331f983
Author: Michael Neuling <mikey@neuling.org>
Date: Thu Sep 26 13:29:09 2013 +1000
powerpc/tm: Switch out userspace PPR and DSCR sooner
When we do a treclaim or trecheckpoint we end up running with userspace
PPR and DSCR values. Currently we don't do anything special to avoid
running with user values which could cause a severe performance
degradation.
This patch moves the PPR and DSCR save and restore around treclaim and
trecheckpoint so that we run with user values for a much shorter period.
More care is taken with the PPR as it's impact is greater than the DSCR.
This is similar to user exceptions, where we run HTM_MEDIUM early to
ensure that we don't run with a userspace PPR values in the kernel.
^ permalink raw reply
* Re: [PATCH 0/3] Add new ptrace request macros on PowerPC
From: Michael Neuling @ 2014-04-29 7:06 UTC (permalink / raw)
To: Anshuman Khandual; +Cc: Linux PPC dev, linux-kernel, avagin, roland, oleg
In-Reply-To: <535F4E10.2020300@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3581 bytes --]
How is it causing the problem?
Mikey
On 29 Apr 2014 17:02, "Anshuman Khandual" <khandual@linux.vnet.ibm.com>
wrote:
>
> On 04/02/2014 03:02 PM, Anshuman Khandual wrote:
> > On 04/02/2014 12:32 PM, Anshuman Khandual wrote:
> >> This patch series adds new ELF note sections which are used to
> >> create new ptrace request macros for various transactional memory and
> >> miscellaneous registers on PowerPC. Please find the test case
exploiting
> >> the new ptrace request macros and it's results on a POWER8 system.
> >>
> >> RFC: https://lkml.org/lkml/2014/4/1/292
> >>
> >> ============================== Results ==============================
> >> -------TM specific SPR------
> >> TM TFHAR: 100009dc
> >> TM TEXASR: de000001ac000001
> >> TM TFIAR: c00000000003f386
> >> TM CH ORIG_MSR: 900000050000f032
> >> TM CH TAR: 6
> >> TM CH PPR: c000000000000
> >> TM CH DSCR: 1
> >> -------TM checkpointed GPR-----
> >> TM CH GPR[0]: 1000097c
> >> TM CH GPR[1]: 5
> >> TM CH GPR[2]: 6
> >> TM CH GPR[7]: 1
> >> TM CH NIP: 100009dc
> >> TM CH LINK: 1000097c
> >> TM CH CCR: 22000422
> >> -------TM running GPR-----
> >> TM RN GPR[0]: 1000097c
> >> TM RN GPR[1]: 7
> >> TM RN GPR[2]: 8
> >> TM RN GPR[7]: 5
> >> TM RN NIP: 100009fc
> >> TM RN LINK: 1000097c
> >> TM RN CCR: 2000422
> >> -------TM running FPR-----
> >> TM RN FPR[0]: 1002d3a3780
> >> TM RN FPR[1]: 7
> >> TM RN FPR[2]: 8
> >> TM RN FPSCR: 0
> >> -------TM checkpointed FPR-----
> >> TM CH FPR[0]: 1002d3a3780
> >> TM CH FPR[1]: 5
> >> TM CH FPR[2]: 6
> >> TM CH FPSCR: 0
> >> -------Running miscellaneous registers-------
> > TM RN DSCR: 0
> >
> > There is a problem in here which I forgot to mention. The running DSCR
value
> > comes from thread->dscr component of the target process. While we are
inside the
> > transaction (which is the case here as we are stuck at "b ."
instruction and
> > have not reached TEND) thread->dscr should have the running value of
the DSCR
> > register at that point of time. Here we expect the DSCR value to be 5
instead
> > of 0 as shown in the output above. During the tests when I moved the "b
." after
> > TEND, the thread->dscr gets the value of 5 while all check pointed reg
values are
> > thrown away. I believe there is some problem in the way thread->dscr
context
> > is saved away inside the TM section. Will look into this problem
further and
> > keep informed.
>
> Reason behind this inconsistent DSCR register value is because of the
following commit
> where the kernel reverts the DSCR register into a default value to avoid
running with
> the user set value for a long time, thus preventing any potential
performance degradation.
> Same reason applies to the PPR register as well. So its not a problem but
an expected
> behaviour.
>
> commit e9bdc3d6143d1c4b8d8ce5231fc958268331f983
> Author: Michael Neuling <mikey@neuling.org>
> Date: Thu Sep 26 13:29:09 2013 +1000
>
> powerpc/tm: Switch out userspace PPR and DSCR sooner
>
> When we do a treclaim or trecheckpoint we end up running with
userspace
> PPR and DSCR values. Currently we don't do anything special to avoid
> running with user values which could cause a severe performance
> degradation.
>
> This patch moves the PPR and DSCR save and restore around treclaim and
> trecheckpoint so that we run with user values for a much shorter
period.
> More care is taken with the PPR as it's impact is greater than the
DSCR.
>
> This is similar to user exceptions, where we run HTM_MEDIUM early to
> ensure that we don't run with a userspace PPR values in the kernel.
>
[-- Attachment #2: Type: text/html, Size: 4832 bytes --]
^ permalink raw reply
* Re: [PATCH V3 2/2] powerpc/pseries: init fault_around_order for pseries
From: Ingo Molnar @ 2014-04-29 7:06 UTC (permalink / raw)
To: Madhavan Srinivasan
Cc: linux-arch, riel, rusty, dave.hansen, peterz, x86, linux-kernel,
linux-mm, ak, paulus, mgorman, Linus Torvalds, akpm, linuxppc-dev,
kirill.shutemov
In-Reply-To: <1398675690-16186-3-git-send-email-maddy@linux.vnet.ibm.com>
* Madhavan Srinivasan <maddy@linux.vnet.ibm.com> wrote:
> Performance data for different FAULT_AROUND_ORDER values from 4 socket
> Power7 system (128 Threads and 128GB memory). perf stat with repeat of 5
> is used to get the stddev values. Test ran in v3.14 kernel (Baseline) and
> v3.15-rc1 for different fault around order values.
>
> FAULT_AROUND_ORDER Baseline 1 3 4 5 8
>
> Linux build (make -j64)
> minor-faults 47,437,359 35,279,286 25,425,347 23,461,275 22,002,189 21,435,836
> times in seconds 347.302528420 344.061588460 340.974022391 348.193508116 348.673900158 350.986543618
> stddev for time ( +- 1.50% ) ( +- 0.73% ) ( +- 1.13% ) ( +- 1.01% ) ( +- 1.89% ) ( +- 1.55% )
> %chg time to baseline -0.9% -1.8% 0.2% 0.39% 1.06%
Probably too noisy.
> Linux rebuild (make -j64)
> minor-faults 941,552 718,319 486,625 440,124 410,510 397,416
> times in seconds 30.569834718 31.219637539 31.319370649 31.434285472 31.972367174 31.443043580
> stddev for time ( +- 1.07% ) ( +- 0.13% ) ( +- 0.43% ) ( +- 0.18% ) ( +- 0.95% ) ( +- 0.58% )
> %chg time to baseline 2.1% 2.4% 2.8% 4.58% 2.85%
Here it looks like a speedup. Optimal value: 5+.
> Binutils build (make all -j64 )
> minor-faults 474,821 371,380 269,463 247,715 235,255 228,337
> times in seconds 53.882492432 53.584289348 53.882773216 53.755816431 53.607824348 53.423759642
> stddev for time ( +- 0.08% ) ( +- 0.56% ) ( +- 0.17% ) ( +- 0.11% ) ( +- 0.60% ) ( +- 0.69% )
> %chg time to baseline -0.55% 0.0% -0.23% -0.51% -0.85%
Probably too noisy, but looks like a potential slowdown?
> Two synthetic tests: access every word in file in sequential/random order.
>
> Sequential access 16GiB file
> FAULT_AROUND_ORDER Baseline 1 3 4 5 8
> 1 thread
> minor-faults 263,148 131,166 32,908 16,514 8,260 1,093
> times in seconds 53.091138345 53.113191672 53.188776177 53.233017218 53.206841347 53.429979442
> stddev for time ( +- 0.06% ) ( +- 0.07% ) ( +- 0.08% ) ( +- 0.09% ) ( +- 0.03% ) ( +- 0.03% )
> %chg time to baseline 0.04% 0.18% 0.26% 0.21% 0.63%
Speedup, optimal value: 8+.
> 8 threads
> minor-faults 2,097,267 1,048,753 262,237 131,397 65,621 8,274
> times in seconds 55.173790028 54.591880790 54.824623287 54.802162211 54.969680503 54.790387715
> stddev for time ( +- 0.78% ) ( +- 0.09% ) ( +- 0.08% ) ( +- 0.07% ) ( +- 0.28% ) ( +- 0.05% )
> %chg time to baseline -1.05% -0.63% -0.67% -0.36% -0.69%
Looks like a regression?
> 32 threads
> minor-faults 8,388,751 4,195,621 1,049,664 525,461 262,535 32,924
> times in seconds 60.431573046 60.669110744 60.485336388 60.697789706 60.077959564 60.588855032
> stddev for time ( +- 0.44% ) ( +- 0.27% ) ( +- 0.46% ) ( +- 0.67% ) ( +- 0.31% ) ( +- 0.49% )
> %chg time to baseline 0.39% 0.08% 0.44% -0.58% 0.25%
Probably too noisy.
> 64 threads
> minor-faults 16,777,409 8,607,527 2,289,766 1,202,264 598,405 67,587
> times in seconds 96.932617720 100.675418760 102.109880836 103.881733383 102.580199555 105.751194041
> stddev for time ( +- 1.39% ) ( +- 1.06% ) ( +- 0.99% ) ( +- 0.76% ) ( +- 1.65% ) ( +- 1.60% )
> %chg time to baseline 3.86% 5.34% 7.16% 5.82% 9.09%
Speedup, optimal value: 4+
> 128 threads
> minor-faults 33,554,705 17,375,375 4,682,462 2,337,245 1,179,007 134,819
> times in seconds 128.766704495 115.659225437 120.353046307 115.291871270 115.450886036 113.991902150
> stddev for time ( +- 2.93% ) ( +- 0.30% ) ( +- 2.93% ) ( +- 1.24% ) ( +- 1.03% ) ( +- 0.70% )
> %chg time to baseline -10.17% -6.53% -10.46% -10.34% -11.47%
Rather significant regression at order 1 already.
> Random access 1GiB file
> FAULT_AROUND_ORDER Baseline 1 3 4 5 8
> 1 thread
> minor-faults 17,155 8,678 2,126 1,097 581 134
> times in seconds 51.904430523 51.658017987 51.919270792 51.560531738 52.354431597 51.976469502
> stddev for time ( +- 3.19% ) ( +- 1.35% ) ( +- 1.56% ) ( +- 0.91% ) ( +- 1.70% ) ( +- 2.02% )
> %chg time to baseline -0.47% 0.02% -0.66% 0.86% 0.13%
Probably too noisy.
> 8 threads
> minor-faults 131,844 70,705 17,457 8,505 4,251 598
> times in seconds 58.162813956 54.991706305 54.952675791 55.323057492 54.755587379 53.376722828
> stddev for time ( +- 1.44% ) ( +- 0.69% ) ( +- 1.23% ) ( +- 2.78% ) ( +- 1.90% ) ( +- 2.91% )
> %chg time to baseline -5.45% -5.52% -4.88% -5.86% -8.22%
Regression.
> 32 threads
> minor-faults 524,437 270,760 67,069 33,414 16,641 2,204
> times in seconds 69.981777072 76.539570015 79.753578505 76.245943618 77.254258344 79.072596831
> stddev for time ( +- 2.81% ) ( +- 1.95% ) ( +- 2.66% ) ( +- 0.99% ) ( +- 2.35% ) ( +- 3.22% )
> %chg time to baseline 9.37% 13.96% 8.95% 10.39% 12.98%
Speedup, optimal value hard to tell due to noise - 3+ or 8+.
> 64 threads
> minor-faults 1,049,117 527,451 134,016 66,638 33,391 4,559
> times in seconds 108.024517536 117.575067996 115.322659914 111.943998437 115.049450815 119.218450840
> stddev for time ( +- 2.40% ) ( +- 1.77% ) ( +- 1.19% ) ( +- 3.29% ) ( +- 2.32% ) ( +- 1.42% )
> %chg time to baseline 8.84% 6.75% 3.62% 6.5% 10.3%
Speedup, optimal value again hard to tell due to noise.
> 128 threads
> minor-faults 2,097,440 1,054,360 267,042 133,328 66,532 8,652
> times in seconds 155.055861167 153.059625968 152.449492156 151.024005282 150.844647770 155.954366718
> stddev for time ( +- 1.32% ) ( +- 1.14% ) ( +- 1.32% ) ( +- 0.81% ) ( +- 0.75% ) ( +- 0.72% )
> %chg time to baseline -1.28% -1.68% -2.59% -2.71% 0.57%
Slowdown for most orders.
> Incase of Kernel compilation, fault around order (fao) of 1 and 3
> provides fast compilation time when compared to a value of 4. On
> closer look, fao of 3 has higher agains. Incase of Sequential access
> synthetic tests fao of 1 has higher gains and in Random access test,
> fao of 3 has marginal gains. Going by compilation time, fao value of
> 3 is suggested in this patch for pseries platform.
So I'm really at loss to understand where you get the optimal value of
'3' from. The data does not seem to match your claim that '1 and 3
provides fast compilation time when compared to a value of 4':
> FAULT_AROUND_ORDER Baseline 1 3 4 5 8
>
> Linux rebuild (make -j64)
> minor-faults 941,552 718,319 486,625 440,124 410,510 397,416
> times in seconds 30.569834718 31.219637539 31.319370649 31.434285472 31.972367174 31.443043580
> stddev for time ( +- 1.07% ) ( +- 0.13% ) ( +- 0.43% ) ( +- 0.18% ) ( +- 0.95% ) ( +- 0.58% )
> %chg time to baseline 2.1% 2.4% 2.8% 4.58% 2.85%
5 and 8, and probably 6, 7 are better than 4.
3 is probably _slower_ than the current default - but it's hard to
tell due to inherent noise.
But the other two build tests were too noisy, and if then they showed
a slowdown.
> Worst case scenario: we touch one page every 16M to demonstrate overhead.
>
> Touch only one page in page table in 16GiB file
> FAULT_AROUND_ORDER Baseline 1 3 4 5 8
> 1 thread
> minor-faults 1,104 1,090 1,071 1,068 1,065 1,063
> times in seconds 0.006583298 0.008531502 0.019733795 0.036033763 0.062300553 0.406857086
> stddev for time ( +- 2.79% ) ( +- 2.42% ) ( +- 3.47% ) ( +- 2.81% ) ( +- 2.01% ) ( +- 1.33% )
> 8 threads
> minor-faults 8,279 8,264 8,245 8,243 8,239 8,240
> times in seconds 0.044572398 0.057211811 0.107606306 0.205626815 0.381679120 2.647979955
> stddev for time ( +- 1.95% ) ( +- 2.98% ) ( +- 1.74% ) ( +- 2.80% ) ( +- 2.01% ) ( +- 1.86% )
> 32 threads
> minor-faults 32,879 32,864 32,849 32,845 32,839 32,843
> times in seconds 0.197659343 0.218486087 0.445116407 0.694235883 1.296894038 9.127517045
> stddev for time ( +- 3.05% ) ( +- 3.05% ) ( +- 4.33% ) ( +- 3.08% ) ( +- 3.75% ) ( +- 0.56% )
> 64 threads
> minor-faults 65,680 65,664 65,646 65,645 65,640 65,647
> times in seconds 0.455537304 0.489688780 0.866490093 1.427393118 2.379628982 17.059295051
> stddev for time ( +- 4.01% ) ( +- 4.13% ) ( +- 2.92% ) ( +- 1.68% ) ( +- 1.79% ) ( +- 0.48% )
> 128 threads
> minor-faults 131,279 131,265 131,250 131,245 131,241 131,254
> times in seconds 1.026880651 1.095327536 1.721728274 2.808233068 4.662729948 31.732848290
> stddev for time ( +- 6.85% ) ( +- 4.09% ) ( +- 1.71% ) ( +- 3.45% ) ( +- 2.40% ) ( +- 0.68% )
There's no '%change' values shown, but the slowdown looks significant,
it's the worst case: for example with 1 thread order 3 looks about
300% slower (3x slowdown) compared to order 0.
All in one, looking at your latest data I don't think the conclusion
from your first version of this optimization patch from a month ago is
true anymore:
> + /* Measured on a 4 socket Power7 system (128 Threads and 128GB memory) */
> + fault_around_order = 3;
As the data is rather conflicting and inconclusive, and if it shows a
sweet spot it's not at order 3. New data should in general trigger
reanalysis of your first optimization value.
I'm starting to suspect that maybe workloads ought to be given a
choice in this matter, via madvise() or such.
Thanks,
Ingo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox