[PATCH] powerpc/le: Fix module build error
I made a cleanup suggestion on 27143b9a0 (powerpc/le: Avoid creatng R_PPC64_TOCSAVE relocations for modules) that had a stupid typo. Fix it. Signed-off-by: Anton Blanchard an...@samba.org --- diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index a9f814a..4c0cedf 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -74,7 +74,7 @@ override CROSS32AS += -mlittle-endian LDEMULATION:= lppc GNUTARGET := powerpcle MULTIPLEWORD := -mno-multiple -KBUILD_CFLAGS_MODULE += $(call cc-option-yn,-mno-save-toc-indirect) +KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-save-toc-indirect) else ifeq ($(call cc-option-yn,-mbig-endian),y) override CC+= -mbig-endian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: cscope: issue with symlinks in tools/testing/selftests/powerpc/copyloops/
[ removed cscope-devel from Cc:, non-subscriber mails get blocked anyway ] On Mon, 2014-04-07 at 14:42 +0200, Gerhard Sittig wrote: On Mon, 2014-04-07 at 06:42 -0400, Neil Horman wrote: On Thu, Apr 03, 2014 at 03:16:15PM +0200, Yann Droneaud wrote: [ ... ] cscope reports error when generating the cross-reference database: $ make ALLSOURCE_ARCHS=all O=./obj-cscope/ cscope GEN cscope cscope: cannot find file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_power7.S cscope: cannot find file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_64.S cscope: cannot find file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_power7.S cscope: cannot find file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_64.S And when calling cscope from ./obj-cscope/ directory, it reports errors too. Hopefully it doesn't stop it from working, so I'm still able to use cscope to browse kernel sources. No, it won't stop it from working, it just won't search those files. I don't recall exactly the reason, but IIRC there was a big discussion long ago about symlinks and our ability to support them (around version 1.94 I think). We decided to not handle symlinks, as they would either point outside our search tree, which we didn't want to include, or would point to another file in the search tree, which made loading them pointless (as we would cover the search in the pointed file). So there are valid reasons to not process those filesystem entries. Would it be useful to not emit the warnings then? Or to silent those warnings when the user knows it's perfectly legal to skip those filesytem entries? Like what you can do with the ctags(1) command and its --links option. For the record: I got a response off list (actually to the cscope list only which is closed for non-subscribers, while the Linux related recipients were removed despite the fact that the issue appears to be in Linux), see http://article.gmane.org/gmane.comp.programming.tools.cscope.devel/105 This reponse suggests that the issue is not in cscope(1) itself, but instead is in how the cscope(1) command got invoked. Which translates into the Linux infrastructure does something wrong. A quick search identifies ./scripts/tags.sh:all_target_sources() as the spot where symlinks should get filtered out. Where both paths of all_target_sources() end up calling all_sources(). virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] power, sched: stop updating inside arch_update_cpu_topology() when nothing to be update
On 04/08/2014 08:49 AM, Michael wang wrote: Since v1: Edited the comment according to Srivatsa's suggestion. During the testing, we encounter below WARN followed by Oops: WARNING: at kernel/sched/core.c:6218 ... NIP [c0101660] .build_sched_domains+0x11d0/0x1200 LR [c0101358] .build_sched_domains+0xec8/0x1200 PACATMSCRATCH [8000f032] Call Trace: [c0001b103850] [c0101358] .build_sched_domains+0xec8/0x1200 [c0001b1039a0] [c010aad4] .partition_sched_domains+0x484/0x510 [c0001b103aa0] [c016d0a8] .rebuild_sched_domains+0x68/0xa0 [c0001b103b30] [c005cbf0] .topology_work_fn+0x10/0x30 ... Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c045c000] .__bitmap_weight+0x60/0xf0 LR [c010132c] .build_sched_domains+0xe9c/0x1200 PACATMSCRATCH [80029032] Call Trace: [c0001b1037a0] [c0288ff4] .kmem_cache_alloc_node_trace+0x184/0x3a0 [c0001b103850] [c010132c] .build_sched_domains+0xe9c/0x1200 [c0001b1039a0] [c010aad4] .partition_sched_domains+0x484/0x510 [c0001b103aa0] [c016d0a8] .rebuild_sched_domains+0x68/0xa0 [c0001b103b30] [c005cbf0] .topology_work_fn+0x10/0x30 ... This was caused by that 'sd-groups == NULL' after building groups, which was caused by the empty 'sd-span'. The cpu's domain contained nothing because the cpu was assigned to a wrong node, due to the following unfortunate sequence of events: 1. The hypervisor sent a topology update to the guest OS, to notify changes to the cpu-node mapping. However, the update was actually redundant - i.e., the new mapping was exactly the same as the old one. 2. Due to this, the 'updated_cpus' mask turned out to be empty after exiting the 'for-loop' in arch_update_cpu_topology(). 3. So we ended up calling stop-machine() with an empty cpumask list, which made stop-machine internally elect cpumask_first(cpu_online_mask), i.e., CPU0 as the cpu to run the payload (the update_cpu_topology() function). 4. This causes update_cpu_topology() to be run by CPU0. And since 'updates' is kzalloc()'ed inside arch_update_cpu_topology(), update_cpu_topology() finds update-cpu as well as update-new_nid to be 0. In other words, we end up assigning CPU0 (and eventually its siblings) to node 0, incorrectly. Along with the following wrong updating, it causes the sched-domain rebuild code to break and crash the system. Fix this by skipping the topology update in cases where we find that the topology has not actually changed in reality (ie., spurious updates). CC: Benjamin Herrenschmidt b...@kernel.crashing.org CC: Paul Mackerras pau...@samba.org CC: Nathan Fontenot nf...@linux.vnet.ibm.com CC: Stephen Rothwell s...@canb.auug.org.au CC: Andrew Morton a...@linux-foundation.org CC: Robert Jennings r...@linux.vnet.ibm.com CC: Jesse Larrew jlar...@linux.vnet.ibm.com CC: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com CC: Alistair Popple alist...@popple.id.au Suggested-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com Signed-off-by: Michael Wang wang...@linux.vnet.ibm.com --- Reviewed-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com Regards, Srivatsa S. Bhat arch/powerpc/mm/numa.c | 15 +++ 1 file changed, 15 insertions(+) diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c index 30a42e2..4ebbb9e 100644 --- a/arch/powerpc/mm/numa.c +++ b/arch/powerpc/mm/numa.c @@ -1591,6 +1591,20 @@ int arch_update_cpu_topology(void) cpu = cpu_last_thread_sibling(cpu); } + /* + * In cases where we have nothing to update (because the updates list + * is too short or because the new topology is same as the old one), + * skip invoking update_cpu_topology() via stop-machine(). This is + * necessary (and not just a fast-path optimization) since stop-machine + * can end up electing a random CPU to run update_cpu_topology(), and + * thus trick us into setting up incorrect cpu-node mappings (since + * 'updates' is kzalloc()'ed). + * + * And for the similar reason, we will skip all the following updating. + */ + if (!cpumask_weight(updated_cpus)) + goto out; + stop_machine(update_cpu_topology, updates[0], updated_cpus); /* @@ -1612,6 +1626,7 @@ int arch_update_cpu_topology(void) changed = 1; } +out: kfree(updates); return changed; } ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: cscope: issue with symlinks in tools/testing/selftests/powerpc/copyloops/
On Tue, Apr 08, 2014 at 09:56:10AM +0200, Gerhard Sittig wrote: [ removed cscope-devel from Cc:, non-subscriber mails get blocked anyway ] On Mon, 2014-04-07 at 14:42 +0200, Gerhard Sittig wrote: On Mon, 2014-04-07 at 06:42 -0400, Neil Horman wrote: On Thu, Apr 03, 2014 at 03:16:15PM +0200, Yann Droneaud wrote: [ ... ] cscope reports error when generating the cross-reference database: $ make ALLSOURCE_ARCHS=all O=./obj-cscope/ cscope GEN cscope cscope: cannot find file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_power7.S cscope: cannot find file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_64.S cscope: cannot find file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_power7.S cscope: cannot find file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_64.S And when calling cscope from ./obj-cscope/ directory, it reports errors too. Hopefully it doesn't stop it from working, so I'm still able to use cscope to browse kernel sources. No, it won't stop it from working, it just won't search those files. I don't recall exactly the reason, but IIRC there was a big discussion long ago about symlinks and our ability to support them (around version 1.94 I think). We decided to not handle symlinks, as they would either point outside our search tree, which we didn't want to include, or would point to another file in the search tree, which made loading them pointless (as we would cover the search in the pointed file). So there are valid reasons to not process those filesystem entries. Would it be useful to not emit the warnings then? Or to silent those warnings when the user knows it's perfectly legal to skip those filesytem entries? Like what you can do with the ctags(1) command and its --links option. For the record: I got a response off list (actually to the cscope list only which is closed for non-subscribers, while the Linux related recipients were removed despite the fact that the issue appears to be in Linux), see http://article.gmane.org/gmane.comp.programming.tools.cscope.devel/105 I don't agree with Hans here. He's right in that the Linux makefiles could exclude the symlinks from the index file that it builds, but if cscope were left to its own devices it would also exclude the assembly files and other code that it doesn't officially parse, but does more or less ok with. We can argue all day weather its ok for Linux to do that, but the facts of the matter is that people use cscope to search the linux source tree asm files and all, and while we could propose that the cscope makefile target filter out symlinks, it seems IMHO to be more difficult than its worth. Adding code to silence db build warnings would be good. This reponse suggests that the issue is not in cscope(1) itself, but instead is in how the cscope(1) command got invoked. Which translates into the Linux infrastructure does something wrong. A quick search identifies ./scripts/tags.sh:all_target_sources() as the spot where symlinks should get filtered out. Where both paths of all_target_sources() end up calling all_sources(). virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_sai: Fix Bit Clock Polarity configurations
On Fri, Apr 04, 2014 at 11:05:32AM +0100, Mark Brown wrote: On Fri, Apr 04, 2014 at 03:09:47PM +0800, Nicolin Chen wrote: The BCP bit in TCR4/RCR4 register rules as followings: 0 Bit clock is active high with drive outputs on rising edge and sample inputs on falling edge. 1 Bit clock is active low with drive outputs on falling edge and sample inputs on rising edge. Applied, thanks. Sir, I can't find this patch on any of the remote branches: for-next, topic/fsl-sai and fix/fsl-sai. Where could I find it? Thank you, Nicolin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_sai: Fix Bit Clock Polarity configurations
On Tue, Apr 08, 2014 at 07:07:40PM +0800, Nicolin Chen wrote: Sir, I can't find this patch on any of the remote branches: for-next, topic/fsl-sai and fix/fsl-sai. Where could I find it? It's in the fix branch. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [1/2,v9] powerpc/mpc85xx:Add initial device tree support of T104x
On Sun, 2014-04-06 at 18:48 +0530, Prabhakar Kushwaha wrote:
On 3/20/2014 4:03 AM, Scott Wood wrote:
On Sat, Jan 25, 2014 at 05:10:59PM +0530, Prabhakar Kushwaha wrote:
+ clockgen: global-utilities@e1000 {
+ compatible = fsl,t1040-clockgen, fsl,qoriq-clockgen-2.0,
+ fixed-clock;
+ ranges = 0x0 0xe1000 0x1000;
+ clock-frequency = 1;
Why is clock-frequency hardcoded here rather than supplied by U-Boot?
Especially since this is an SoC file, not a board file.
Your are correct.
Means, clock-frequency should be added to clockgen in board device tree ??
Usually it gets patched in by U-Boot.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/3] devcietree: bindings: add some MFD Keymile FPGAs
On Tue, 2014-03-25 at 14:41 +0100, Valentin Longchamp wrote:
These are the bindings for 2 MFD devices used on some of the Keymile boards.
The first one is the chassis managmenet bfticu FPGA.
The second one is the board controller (reset, LEDs, GPIOs) QRIO CPDL.
These FPGAs are used in the kmcoge4 board.
This patch also add KEYMILE to the vendor-prefixes.
Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
---
Changes in v3:
- add a patch with the bindings for the KEYMILE FPGAs
Changes in v2: None
Documentation/devicetree/bindings/mfd/bfticu.txt | 26
++
Documentation/devicetree/bindings/mfd/qriox.txt| 17 ++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
3 files changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/bfticu.txt
create mode 100644 Documentation/devicetree/bindings/mfd/qriox.txt
diff --git a/Documentation/devicetree/bindings/mfd/bfticu.txt
b/Documentation/devicetree/bindings/mfd/bfticu.txt
new file mode 100644
index 000..92de32e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/bfticu.txt
@@ -0,0 +1,26 @@
+KEYMILE bfticu Chassis Management FPGA
+
+The bfticu is a multifunction device that manages the whole chassis.
+Its main functionality is to collect IRQs from the whole chassis and signals
+them to a single controller.
+
+Required properties:
+- compatible: keymile,bfticu
+- interrupt-controller: the bfticu FPGA is an interrupt controller
+- interrupts: the main IRQ line to signal the collected IRQs
+- #interrupt-cells : is 2
+ - The 1st cell is the local IRQ number on the bfticu
+ - The 2nd cell is the type of the IRQ (IRQ_TYPE_xxx)
Device tree bindings should not depend on the content of Linux headers.
One is stable ABI, and the other isn't.
If you want you can make the values the same for convenience, as is done
by IPIC, CPM PIC, etc -- but the values need to be explicitly stated in
the binding. It'll still break if the Linux values change (so it may
not be a good idea to try to keep the values the same), but at least the
fix would be in Linux code rather than an ABI change.
diff --git a/Documentation/devicetree/bindings/mfd/qriox.txt
b/Documentation/devicetree/bindings/mfd/qriox.txt
new file mode 100644
index 000..f301e2d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/qriox.txt
@@ -0,0 +1,17 @@
+KEYMILE qrio Board Control CPLD
+
+The qrio is a multifunction device that controls the KEYMILE boards based on
+the kmp204x design.
+It is consists of a reset controller, watchdog timer, LEDs, and 2 IRQ capable
+GPIO blocks.
+
+Required properties:
+- compatible: keymile,qriox
+- reg: access on the parent local bus (chip select, offset in chip select,
size)
+
+Example:
+
+ board-control@1,0 {
+ compatible = keymile,qriox;
+ reg = 1 0 0x80;
+ };
If it has GPIO blocks, shouldn't it be using the GPIO binding?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] powerpc/mpc85xx: add support for Keymile's kmcoge4 board
On Tue, 2014-03-25 at 14:41 +0100, Valentin Longchamp wrote:
+ lbc: localbus@ffe124000 {
+ reg = 0xf 0xfe124000 0 0x1000;
+ ranges = 0 0 0xf 0xffa0 0x0004 /* LB 0 */
+ 1 0 0xf 0xfb00 0x0001 /* LB 1 */
+ 2 0 0xf 0xd000 0x1000 /* LB 2 */
+ 3 0 0xf 0xe000 0x1000; /* LB 3 */
+
+ nand@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,elbc-fcm-nand;
+ reg = 0 0 0x4;
+
+ partition@0 {
+ label = ubi0;
+ reg = 0x0 0x1000;
+ };
Putting partition info in the dts file is a bad habit and (as I've told
others) I don't think we should continue doing so in new dts files.
In this case it looks like you're just making the entire chip into one
partition, so I'm not sure what the point is of partitioning at all.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/qe: Setup clock source for TDM
On Tue, 2014-03-18 at 17:09 +0800, Xie Xiaobo wrote:
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 238a07b..9a9f733 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -1,5 +1,6 @@
/*
- * Copyright (C) 2006-2010 Freescale Semiconductor, Inc. All rights reserved.
+ * Copyright (C) 2006-2010, 2014 Freescale Semiconductor, Inc.
+ * All rights reserved.
*
* Authors: Shlomi Gridish grid...@freescale.com
* Li Yang le...@freescale.com
@@ -240,6 +241,12 @@ enum qe_clock qe_clock_source(const char *source)
if (strcasecmp(source, none) == 0)
return QE_CLK_NONE;
+ if (strcasecmp(source, tsync_pin) == 0)
+ return QE_TSYNC_PIN;
+
+ if (strcasecmp(source, rsync_pin) == 0)
+ return QE_RSYNC_PIN;
+
Binding update?
@@ -210,3 +210,774 @@ int ucc_set_qe_mux_rxtx(unsigned int ucc_num, enum
qe_clock clock,
return 0;
}
+
+/* tdm_num: TDM A-H port num is 0-7 */
+int ucc_set_tdm_rxtx_clk(u32 tdm_num, enum qe_clock clock,
+ enum comm_dir mode)
+{
+ u32 clock_bits, shift;
+ struct qe_mux *qe_mux_reg;
+ __be32 __iomem *cmxs1cr;
+
+ clock_bits = 0;
+ qe_mux_reg = qe_immr-qmx;
+
+ if ((tdm_num 7 || tdm_num 0))
+ return -EINVAL;
+
+ /* The communications direction must be RX or TX */
+ if (!((mode == COMM_DIR_RX) || (mode == COMM_DIR_TX)))
+ return -EINVAL;
Unnecessary parentheses.
tdm_num cannot be 0 as it is unsigned.
Use a symbolic name rather than 7.
+ switch (mode) {
+ case COMM_DIR_RX:
+ switch (tdm_num) {
+ case 0:
+ switch (clock) {
+ case QE_BRG3:
+ clock_bits = 1;
+ break;
+ case QE_BRG4:
+ clock_bits = 2;
+ break;
+ case QE_CLK1:
+ clock_bits = 4;
+ break;
+ case QE_CLK2:
+ clock_bits = 5;
+ break;
+ case QE_CLK3:
+ clock_bits = 6;
+ break;
+ case QE_CLK8:
+ clock_bits = 7;
+ break;
+ default:
+ break;
+ }
+ shift = 28;
+ break;
+ case 1:
+ switch (clock) {
+ case QE_BRG3:
+ clock_bits = 1;
+ break;
+ case QE_BRG4:
+ clock_bits = 2;
+ break;
+ case QE_CLK1:
+ clock_bits = 4;
+ break;
+ case QE_CLK2:
+ clock_bits = 5;
+ break;
+ case QE_CLK5:
+ clock_bits = 6;
+ break;
+ case QE_CLK10:
+ clock_bits = 7;
+ break;
+ default:
+ break;
+ }
+ shift = 24;
+ break;
+ case 2:
+ switch (clock) {
+ case QE_BRG3:
+ clock_bits = 1;
+ break;
+ case QE_BRG4:
+ clock_bits = 2;
+ break;
+ case QE_CLK1:
+ clock_bits = 4;
+ break;
+ case QE_CLK2:
+ clock_bits = 5;
+ break;
+ case QE_CLK7:
+ clock_bits = 6;
+ break;
+ case QE_CLK12:
+ clock_bits = 7;
+ break;
+ default:
+ break;
+ }
+ shift = 20;
+ break;
+ case 3:
+ switch (clock) {
+ case QE_BRG3:
+
Re: [PATCH V2 1/2] mm: move FAULT_AROUND_ORDER to arch/
On Friday 04 April 2014 06:47 PM, Kirill A. Shutemov wrote:
On Fri, Apr 04, 2014 at 11:57:14AM +0530, Madhavan Srinivasan wrote:
Kirill A. Shutemov with faultaround patchset 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 move the FAULT_AROUND_ORDER
to arch/ using Kconfig. This will enable architecture maintainers
to decide on suitable FAULT_AROUND_ORDER value based on
performance data for that architecture. Patch also adds
FAULT_AROUND_ORDER Kconfig element in arch/X86.
Signed-off-by: Madhavan Srinivasan ma...@linux.vnet.ibm.com
---
arch/x86/Kconfig |4
include/linux/mm.h |9 +
mm/memory.c| 12 +---
3 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 9c0a657..5833f22 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1177,6 +1177,10 @@ config DIRECT_GBPAGES
support it. This can improve the kernel's performance a tiny bit by
reducing TLB pressure. If in doubt, say Y.
+config FAULT_AROUND_ORDER
+int
+default 4
+
# Common NUMA Features
config NUMA
bool Numa Memory Allocation and Scheduler Support
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0bd4359..b93c1c3 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -26,6 +26,15 @@ struct file_ra_state;
struct user_struct;
struct writeback_control;
+/*
+ * Fault around order is a control knob to decide the fault around pages.
+ * Default value is set to 0UL (disabled), but the arch can override it as
+ * desired.
+ */
+#ifndef CONFIG_FAULT_AROUND_ORDER
+#define CONFIG_FAULT_AROUND_ORDER 0
+#endif
+
I don't think it should be in header file: nobody except mm/memory.c cares.
Just put it instead '#define FAULT_AROUND_ORDER'.
Ok. Will do this change.
#ifndef CONFIG_NEED_MULTIPLE_NODES /* Don't use mapnrs, do it properly */
extern unsigned long max_mapnr;
diff --git a/mm/memory.c b/mm/memory.c
index b02c584..22a4a89 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3358,10 +3358,8 @@ void do_set_pte(struct vm_area_struct *vma, unsigned
long address,
update_mmu_cache(vma, address, pte);
}
-#define FAULT_AROUND_ORDER 4
-
#ifdef CONFIG_DEBUG_FS
-static unsigned int fault_around_order = FAULT_AROUND_ORDER;
+static unsigned int fault_around_order = CONFIG_FAULT_AROUND_ORDER;
static int fault_around_order_get(void *data, u64 *val)
{
@@ -3371,7 +3369,7 @@ 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);
+BUILD_BUG_ON((1UL CONFIG_FAULT_AROUND_ORDER) PTRS_PER_PTE);
if (1UL val PTRS_PER_PTE)
return -EINVAL;
fault_around_order = val;
@@ -3406,14 +3404,14 @@ static inline unsigned long fault_around_pages(void)
{
unsigned long nr_pages;
-nr_pages = 1UL FAULT_AROUND_ORDER;
+nr_pages = 1UL CONFIG_FAULT_AROUND_ORDER;
BUILD_BUG_ON(nr_pages PTRS_PER_PTE);
return nr_pages;
}
static inline unsigned long fault_around_mask(void)
{
-return ~((1UL (PAGE_SHIFT + FAULT_AROUND_ORDER)) - 1);
+return ~((1UL (PAGE_SHIFT + CONFIG_FAULT_AROUND_ORDER)) - 1);
}
#endif
@@ -3471,7 +3469,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_pages() 1)) {
if (vma-vm_ops-map_pages fault_around_pages()) {
For a fault around value of 0, fault_around_pages() will return 1 and
that is reason for checking it greater than 1. Also, using debug fs,
fault around value can be zeroed.
With regards
Maddy
pte = pte_offset_map_lock(mm, pmd, address, ptl);
do_fault_around(vma, address, pte, pgoff, flags);
if (!pte_same(*pte, orig_pte))
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 1/2] mm: move FAULT_AROUND_ORDER to arch/
On Friday 04 April 2014 09:48 PM, Dave Hansen wrote: On 04/03/2014 11:27 PM, Madhavan Srinivasan wrote: This patch creates infrastructure to move the FAULT_AROUND_ORDER to arch/ using Kconfig. This will enable architecture maintainers to decide on suitable FAULT_AROUND_ORDER value based on performance data for that architecture. Patch also adds FAULT_AROUND_ORDER Kconfig element in arch/X86. Please don't do it this way. In mm/Kconfig, put config FAULT_AROUND_ORDER int default 1234 if POWERPC default 4 The way you have it now, every single architecture that needs to enable this has to go put that in their Kconfig. That's madness. This way, I though about it and decided not to do this way because, in future, sub platforms of the architecture may decide to change the values. Also, adding an if line for each architecture with different sub platforms oring to it will look messy. With regards Maddy you only put it in one place, and folks only have to care if they want to change the default to be something other than 4. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 1/2] mm: move FAULT_AROUND_ORDER to arch/
On Friday 04 April 2014 11:20 PM, David Miller wrote: From: Dave Hansen dave.han...@intel.com Date: Fri, 04 Apr 2014 09:18:43 -0700 On 04/03/2014 11:27 PM, Madhavan Srinivasan wrote: This patch creates infrastructure to move the FAULT_AROUND_ORDER to arch/ using Kconfig. This will enable architecture maintainers to decide on suitable FAULT_AROUND_ORDER value based on performance data for that architecture. Patch also adds FAULT_AROUND_ORDER Kconfig element in arch/X86. Please don't do it this way. In mm/Kconfig, put config FAULT_AROUND_ORDER int default 1234 if POWERPC default 4 The way you have it now, every single architecture that needs to enable this has to go put that in their Kconfig. That's madness. This way, you only put it in one place, and folks only have to care if they want to change the default to be something other than 4. It looks more like it's necessary only to change the default, not to enable it. Unless I read his patch wrong... Yes. With current patch, you only need to change the default by which you enable it. With regards Maddy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
