linaro-kernel December 2013

linaro-kernel@lists.linaro.org

83 participants
265 discussions

[PATCH 00/34] CPUFreq: Move freq change notifications out of drivers

by Viresh Kumar

Another 452 lines gone :) Total stats upto now for all the 5 patchsets: Viresh Kumar (186): ... 69 files changed, 700 insertions(+), 2451 deletions(-) Net: 1751 lines gone.. -----x-------------x---------------- Most of the drivers do following in their ->target_index() routines: struct cpufreq_freqs freqs; freqs.old = old freq... freqs.new = new freq... cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE); /* Change rate here */ cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE); This is replicated over all cpufreq drivers today and there doesn't exists a good enough reason why this shouldn't be moved to cpufreq core instead. There are few special cases though, like exynos5440, which doesn't do everything on the call to ->target_index() routine and call some kind of bottom halves for doing this work, work/tasklet/etc.. They may continue doing notification from their own code and so this patch introduces another flag: CPUFREQ_NO_NOTIFICATION, which will be set by such drivers. This is Fifth part of my cleanup work for CPUFreq, first three are (And obviously its rebased over them): 1: cpufreq: Introduce cpufreq_table_validate_and_show() https://lkml.org/lkml/2013/8/8/263 2: cpufreq: define generic routines for cpufreq drivers https://lkml.org/lkml/2013/8/10/48 3. CPUFreq: Implement light weight ->target(): for 3.13 https://lkml.org/lkml/2013/8/13/349 4. CPUFreq: set policy->cur in cpufreq core instead of drivers https://lkml.org/lkml/2013/8/14/288 All these are pushed here: https://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/… -- viresh Cc: Andrew Lunn <andrew(a)lunn.ch> Cc: David S. Miller <davem(a)davemloft.net> Cc: Dmitry Eremin-Solenikov <dbaryshkov(a)gmail.com> Cc: Eric Miao <eric.y.miao(a)gmail.com> Cc: Hans-Christian Egtvedt <egtvedt(a)samfundet.no> Cc: Jesper Nilsson <jesper.nilsson(a)axis.com> Cc: John Crispin <blogic(a)openwrt.org> Cc: Kukjin Kim <kgene.kim(a)samsung.com> Cc: Linus Walleij <linus.walleij(a)linaro.org> Cc: linux-cris-kernel(a)axis.com Cc: Mikael Starvik <starvik(a)axis.com> Cc: Russell King <linux(a)arm.linux.org.uk> Cc: Santosh Shilimkar <santosh.shilimkar(a)ti.com> Cc: Sekhar Nori <nsekhar(a)ti.com> Cc: Shawn Guo <shawn.guo(a)linaro.org> Cc: sparclinux(a)vger.kernel.org Cc: spear-devel(a)list.st.com Cc: Stephen Warren <swarren(a)nvidia.com> Cc: Steven Miao <realmz6(a)gmail.com> Cc: Tony Luck <tony.luck(a)intel.com> Viresh Kumar (34): cpufreq: move freq change notifications to cpufreq core cpufreq: acpi: remove calls to cpufreq_notify_transition() cpufreq: arm_big_little: remove calls to cpufreq_notify_transition() cpufreq: at32ap: remove calls to cpufreq_notify_transition() cpufreq: blackfin: remove calls to cpufreq_notify_transition() cpufreq: cpu0: remove calls to cpufreq_notify_transition() cpufreq: cris: remove calls to cpufreq_notify_transition() cpufreq: davinci: remove calls to cpufreq_notify_transition() cpufreq: dbx500: remove calls to cpufreq_notify_transition() cpufreq: e_powersaver: remove calls to cpufreq_notify_transition() cpufreq: elanfreq: remove calls to cpufreq_notify_transition() cpufreq: exynos: remove calls to cpufreq_notify_transition() cpufreq: exynos5440: set CPUFREQ_NO_NOTIFICATION flag cpufreq: ia64-acpi: remove calls to cpufreq_notify_transition() cpufreq: imx6q: remove calls to cpufreq_notify_transition() cpufreq: kirkwood: remove calls to cpufreq_notify_transition() cpufreq: longhaul: set CPUFREQ_NO_NOTIFICATION flag cpufreq: loongson2: remove calls to cpufreq_notify_transition() cpufreq: maple: remove calls to cpufreq_notify_transition() cpufreq: omap: remove calls to cpufreq_notify_transition() cpufreq: p4-clockmod: remove calls to cpufreq_notify_transition() cpufreq: pasemi: remove calls to cpufreq_notify_transition() cpufreq: pmac: remove calls to cpufreq_notify_transition() cpufreq: powernow: remove calls to cpufreq_notify_transition() cpufreq: ppc: remove calls to cpufreq_notify_transition() cpufreq: pxa: remove calls to cpufreq_notify_transition() cpufreq: s3c: remove calls to cpufreq_notify_transition() cpufreq: s5pv210: remove calls to cpufreq_notify_transition() cpufreq: sa11x0: remove calls to cpufreq_notify_transition() cpufreq: sc520: remove calls to cpufreq_notify_transition() cpufreq: sparc: remove calls to cpufreq_notify_transition() cpufreq: SPEAr: remove calls to cpufreq_notify_transition() cpufreq: speedstep: remove calls to cpufreq_notify_transition() cpufreq: tegra: remove calls to cpufreq_notify_transition() drivers/cpufreq/acpi-cpufreq.c | 14 ++------- drivers/cpufreq/arm_big_little.c | 25 ++-------------- drivers/cpufreq/at32ap-cpufreq.c | 22 ++++++-------- drivers/cpufreq/blackfin-cpufreq.c | 22 +++++--------- drivers/cpufreq/cpufreq-cpu0.c | 33 ++++++++------------- drivers/cpufreq/cpufreq.c | 34 +++++++++++++++++++++ drivers/cpufreq/cris-artpec3-cpufreq.c | 8 ----- drivers/cpufreq/cris-etraxfs-cpufreq.c | 8 ----- drivers/cpufreq/davinci-cpufreq.c | 30 +++++++------------ drivers/cpufreq/dbx500-cpufreq.c | 22 +------------- drivers/cpufreq/e_powersaver.c | 23 ++------------- drivers/cpufreq/elanfreq.c | 13 -------- drivers/cpufreq/exynos-cpufreq.c | 28 +++++------------- drivers/cpufreq/exynos5440-cpufreq.c | 2 +- drivers/cpufreq/ia64-acpi-cpufreq.c | 19 ------------ drivers/cpufreq/imx6q-cpufreq.c | 39 ++++++++++-------------- drivers/cpufreq/kirkwood-cpufreq.c | 54 +++++++++++++--------------------- drivers/cpufreq/longhaul.c | 1 + drivers/cpufreq/loongson2_cpufreq.c | 16 ---------- drivers/cpufreq/maple-cpufreq.c | 18 +----------- drivers/cpufreq/omap-cpufreq.c | 39 +++++++++--------------- drivers/cpufreq/p4-clockmod.c | 10 ------- drivers/cpufreq/pasemi-cpufreq.c | 14 +-------- drivers/cpufreq/pmac32-cpufreq.c | 20 +++---------- drivers/cpufreq/pmac64-cpufreq.c | 18 +----------- drivers/cpufreq/powernow-k6.c | 8 ----- drivers/cpufreq/powernow-k7.c | 11 +------ drivers/cpufreq/powernow-k8.c | 15 +--------- drivers/cpufreq/ppc-corenet-cpufreq.c | 19 +----------- drivers/cpufreq/ppc_cbe_cpufreq.c | 19 +----------- drivers/cpufreq/pxa2xx-cpufreq.c | 27 ++++------------- drivers/cpufreq/pxa3xx-cpufreq.c | 12 -------- drivers/cpufreq/s3c2416-cpufreq.c | 21 +++---------- drivers/cpufreq/s3c64xx-cpufreq.c | 48 ++++++++++-------------------- drivers/cpufreq/s5pv210-cpufreq.c | 16 ++++------ drivers/cpufreq/sa1100-cpufreq.c | 17 ++++------- drivers/cpufreq/sa1110-cpufreq.c | 12 ++------ drivers/cpufreq/sc520_freq.c | 11 ------- drivers/cpufreq/sparc-us2e-cpufreq.c | 7 ----- drivers/cpufreq/sparc-us3-cpufreq.c | 7 ----- drivers/cpufreq/spear-cpufreq.c | 13 +------- drivers/cpufreq/speedstep-centrino.c | 20 +------------ drivers/cpufreq/speedstep-ich.c | 9 ------ drivers/cpufreq/speedstep-smi.c | 7 ----- drivers/cpufreq/tegra-cpufreq.c | 25 ++++------------ include/linux/cpufreq.h | 6 ++++ 46 files changed, 205 insertions(+), 657 deletions(-) -- 1.7.12.rc2.18.g61b472e

7 years, 2 months

[PATCH v2 0/6] arm64: Add ftrace support

by AKASHI Takahiro

This is my second version of patchset for ftrace support. Actually v1 was submitted serveral weeks ago, but is still moderated. (Just ignore them for now.) There is another implementation from Cavium network, but both works are independent, and my code has additional system call trace support. I confirmed that I could compile the patches on v3.12-rc4 by Linaro's coming 2013.10 gcc (4.8.2), and that the kernel worked on Fast Model with the following tracers: function tracer with dynamic ftrace function graph tracer with dynamic ftrace syscall tracepoint irqsoff & preemptirqsoff (which use CALLER_ADDRx) Also verified with in-kernel tests, FTRACE_SELFTEST, FTRACE_STARTUP_TEST and EVENT_TRACE_TEST_SYSCALLS. Patch[3/6] has warnings from checkpatch, but they follow other arch's style. Please be careful that host's elf.h must have AArch64 definitions, EM_AARCH64 and R_AARCH64_ABS64, to build the kernel. See [4/6]. Issues * Can we optimize register usages in asm (by not saving x0, x1 and x2)? [1/6] * Do we need "fault protection" code in ftrace_modify_code()? [1/6] It exists in x86 and other architectures, but not in arm. * We may be able to use aarch64_insn_patch_text_nosync() instead of ftrace_modify_code().[2/6] But the former function does not use probe_kernel_write(). Is this safe? Changes from v1 to v2: * splitted one patch into some pieces for easier review (especially function tracer + dynamic ftrace + CALLER_ADDRx) * put return_address() in a separate file * renamed __mcount to _mcount (it was my mistake) * changed stackframe handling to get parent's frame pointer * removed ARCH_SUPPORTS_FTRACE_OPS * switched to "hotpatch" interfaces from Huawai * revised descriptions in comments AKASHI Takahiro (6): arm64: Add ftrace support arm64: ftrace: Add dynamic ftrace support arm64: ftrace: Add CALLER_ADDRx macros ftrace: Add arm64 support to recordmcount arm64: ftrace: Add system call tracepoint arm64: Add 'notrace' attribute to unwind_frame() for ftrace arch/arm64/Kconfig | 6 + arch/arm64/include/asm/ftrace.h | 54 +++++++++ arch/arm64/include/asm/syscall.h | 1 + arch/arm64/include/asm/thread_info.h | 1 + arch/arm64/include/asm/unistd.h | 2 + arch/arm64/kernel/Makefile | 9 +- arch/arm64/kernel/arm64ksyms.c | 4 + arch/arm64/kernel/entry-ftrace.S | 211 ++++++++++++++++++++++++++++++++++ arch/arm64/kernel/entry.S | 1 + arch/arm64/kernel/ftrace.c | 186 ++++++++++++++++++++++++++++++ arch/arm64/kernel/ptrace.c | 10 ++ arch/arm64/kernel/return_address.c | 55 +++++++++ arch/arm64/kernel/stacktrace.c | 2 +- scripts/recordmcount.c | 4 + scripts/recordmcount.pl | 5 + 15 files changed, 549 insertions(+), 2 deletions(-) create mode 100644 arch/arm64/include/asm/ftrace.h create mode 100644 arch/arm64/kernel/entry-ftrace.S create mode 100644 arch/arm64/kernel/ftrace.c create mode 100644 arch/arm64/kernel/return_address.c -- 1.7.9.5

10 years, 6 months

[PATCH 0/4] arm64: Add audit support

by AKASHI Takahiro

This patchset adds audit support on arm64. The implementation is just like in other architectures, and so I think little explanation is needed. I verified this patch with some commands on both 64-bit rootfs and 32-bit rootfs(, but only in little-endian): # auditctl -a exit,always -S openat -F path=/etc/inittab # auditctl -a exit,always -F dir=/tmp -F perm=rw # auditctl -a task,always # autrace /bin/ls What else? (Thanks to Clayton for his cross-compiling patch) I'd like to discuss about the following issues: (issues) * AUDIT_ARCH_* Why do we need to distiguish big-endian and little-endian? [2/4] * AArch32 We need to add a check for identifying the endian in 32-bit tasks. [3/4] * syscall no in AArch32 Currently all the definitions are added in unistd32.h with "ifdef __AARCH32_AUDITSYSCALL" to use asm-generic/audit_*.h. [3/4] "ifdef" is necessary to avoid a conflict with 64-bit definitions. Do we need a more sophisticated way? * TIF_AUDITSYSCALL Most architectures, except x86, do not check TIF_AUDITSYSCALL. Why not? [4/4] * Userspace audit package There are some missing syscall definitions in lib/aarch64_table.h. There is no support for AUDIT_ARCH_ARM (I mean LE. armeb is BE). AKASHI Takahiro (4): audit: Enable arm64 support arm64: Add audit support arm64: audit: Add AArch32 support arm64: audit: Add audit hook in ptrace/syscall_trace arch/arm64/Kconfig | 3 + arch/arm64/include/asm/audit32.h | 12 ++ arch/arm64/include/asm/ptrace.h | 5 + arch/arm64/include/asm/syscall.h | 18 ++ arch/arm64/include/asm/thread_info.h | 1 + arch/arm64/include/asm/unistd32.h | 387 ++++++++++++++++++++++++++++++++++ arch/arm64/kernel/Makefile | 4 + arch/arm64/kernel/audit.c | 77 +++++++ arch/arm64/kernel/audit32.c | 46 ++++ arch/arm64/kernel/entry.S | 3 + arch/arm64/kernel/ptrace.c | 12 ++ include/uapi/linux/audit.h | 2 + init/Kconfig | 2 +- 13 files changed, 571 insertions(+), 1 deletion(-) create mode 100644 arch/arm64/include/asm/audit32.h create mode 100644 arch/arm64/kernel/audit.c create mode 100644 arch/arm64/kernel/audit32.c -- 1.7.9.5

10 years, 7 months

[PATCH 0/4] ARM: OMAP: raw read and write endian fix

by Taras Kondratiuk

This series does trivial replacement of __raw_xxx functions with xxx_relaxed endian-neutral variants in 'mach-omap2' and 'plat-omap' directories. Some code here most probably won't be used in BE mode (like debug-leds for OMAP1 boards), but changes are made anyway to remove __raw_xxx() functions completely and simplify future grep'ing for new __raw_xxx() entries. This is a part of RFC series [1]. Based on v3.13-rc5. [1] http://www.spinics.net/lists/linux-omap/msg99927.html Victor Kamensky (4): ARM: OMAP2+: raw read and write endian fix ARM: OMAP: dmtimer: raw read and write endian fix ARM: OMAP: counter-32k: raw read and write endian fix ARM: OMAP: debug-leds: raw read and write endian fix arch/arm/mach-omap2/board-flash.c | 4 +-- arch/arm/mach-omap2/clkt2xxx_dpllcore.c | 2 +- arch/arm/mach-omap2/clkt2xxx_osc.c | 8 +++--- arch/arm/mach-omap2/clkt2xxx_sys.c | 2 +- arch/arm/mach-omap2/clkt_clksel.c | 10 +++---- arch/arm/mach-omap2/clkt_dpll.c | 6 ++--- arch/arm/mach-omap2/clkt_iclk.c | 8 +++--- arch/arm/mach-omap2/clock.c | 16 +++++------ arch/arm/mach-omap2/clock36xx.c | 6 ++--- arch/arm/mach-omap2/cm2xxx_3xxx.h | 4 +-- arch/arm/mach-omap2/cm33xx.c | 4 +-- arch/arm/mach-omap2/cm3xxx.c | 8 +++--- arch/arm/mach-omap2/cm44xx.c | 8 +++--- arch/arm/mach-omap2/cminst44xx.c | 4 +-- arch/arm/mach-omap2/control.c | 20 +++++++------- arch/arm/mach-omap2/dma.c | 4 +-- arch/arm/mach-omap2/dpll3xxx.c | 32 +++++++++++----------- arch/arm/mach-omap2/dpll44xx.c | 12 ++++----- arch/arm/mach-omap2/gpmc.c | 8 +++--- arch/arm/mach-omap2/id.c | 2 +- arch/arm/mach-omap2/irq.c | 4 +-- arch/arm/mach-omap2/mux.c | 8 +++--- arch/arm/mach-omap2/omap-hotplug.c | 4 +-- arch/arm/mach-omap2/omap-mpuss-lowpower.c | 18 ++++++------- arch/arm/mach-omap2/omap-smp.c | 4 +-- arch/arm/mach-omap2/omap-wakeupgen.c | 42 ++++++++++++++--------------- arch/arm/mach-omap2/omap4-common.c | 16 +++++------ arch/arm/mach-omap2/omap_hwmod.c | 10 +++---- arch/arm/mach-omap2/omap_phy_internal.c | 6 ++--- arch/arm/mach-omap2/prcm_mpu44xx.c | 4 +-- arch/arm/mach-omap2/prm2xxx.h | 2 +- arch/arm/mach-omap2/prm2xxx_3xxx.h | 4 +-- arch/arm/mach-omap2/prm33xx.c | 4 +-- arch/arm/mach-omap2/prm3xxx.h | 2 +- arch/arm/mach-omap2/prm44xx.c | 4 +-- arch/arm/mach-omap2/prminst44xx.c | 4 +-- arch/arm/mach-omap2/sdrc.h | 8 +++--- arch/arm/mach-omap2/sdrc2xxx.c | 4 +-- arch/arm/mach-omap2/sr_device.c | 2 +- arch/arm/mach-omap2/sram.c | 16 +++++------ arch/arm/mach-omap2/timer.c | 8 +++--- arch/arm/mach-omap2/vc.c | 4 +-- arch/arm/mach-omap2/wd_timer.c | 8 +++--- arch/arm/plat-omap/counter_32k.c | 6 ++--- arch/arm/plat-omap/debug-leds.c | 14 +++++----- arch/arm/plat-omap/dmtimer.c | 8 +++--- arch/arm/plat-omap/include/plat/dmtimer.h | 16 +++++------ 47 files changed, 199 insertions(+), 199 deletions(-) -- 1.7.9.5

10 years, 8 months

[RFC v2 PATCH 0/1] ARM64: KGDB: Add FPSIMD debug support

by vijay.kilari＠gmail.com

From: Vijaya Kumar K <Vijaya.Kumar(a)caviumnetworks.com> Based on ARM64 KGDB support patches, KGDB support for FPSIMD is added. Only debugging of FPSIMD kernel context is supported. This patch requires Ard's patches where in kernel support and below patch for holding thread's fpsimd state. http://permalink.gmane.org/gmane.linux.ports.arm.kernel/277228 So CONFIG_KERNEL_MODE_NEON should be enabled. with this, FPSIMD registers can be viewed or set from gdb tool. Unlike CPU registers, the FPSIMD registers are not saved on exception entry. With the known restriction that FPSIMD should not be touched in interrupt/exception context, in this patch the FPSIMD registers are directly read/written on gdb tool request Here, the FPSIMD registers are read and restored for every FPSIMD register read and write by GDB tool. So this has impact on gdb tool response which is neglible. Other architectures like mips are also implemented similarly v2 changes: - Added API to know thread fpsimd state by checking TIF_FOREIGN_FPSTATE flag. This is based on below patch http://permalink.gmane.org/gmane.linux.ports.arm.kernel/277228 - Allow FPSIMD registers access only when FPSIMD is under use by current thread v1 changes: - Initial patch Tested on ARM64 simulator Vijaya Kumar K (1): ARM64: KGDB: Add FP/SIMD debug support arch/arm64/include/asm/fpsimd.h | 1 + arch/arm64/kernel/fpsimd.c | 5 ++ arch/arm64/kernel/kgdb.c | 105 +++++++++++++++++++++++++-------------- 3 files changed, 73 insertions(+), 38 deletions(-) -- 1.7.9.5

10 years, 9 months

[PATCH v3 0/2] PM / Hibernate: sysfs resume

by Sebastian Capella

Patchsets related to hibernation resume: - enhancement to make the use of an existing resume file more general - enhance name_to_dev_t to ignore trailing newlines coming from userspace. Both patches are based on the 3.12-rc3 tag. This was tested on a Pandaboard with partial hibernation support, and compiled for x86. [PATCH 1/2] init/do_mounts.c: ignore final \n in name_to_dev_t init/do_mounts.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) Changes name_to_dev_t to handle a trailing newline in the input buffer, which will allow name_to_dev_t to be used directly with user buffers without requiring a copy. Also adds a const to the name parameter which reflects how name_to_dev_t is treating the input buffer currently. This also allows direct use of user buffers (from resume_store for example). [PATCH 2/2] PM / Hibernate: use name_to_dev_t to parse resume kernel/power/hibernate.c | 15 ++++----------- 1 file changed, 4 insertions(+), 11 deletions(-) Use name_to_dev_t to parse the /sys/power/resume file making the syntax more flexible. It supports the previous use syntax and additionally can support other formats such as /dev/devicenode and UUID= formats. By changing /sys/debug/resume to accept the same syntax as the resume=device parameter, we can parse the resume=device in the initrd init script and use the resume device directly from the kernel command line. Changes in v3: -------------- * Dropped documentation patch as it went in through trivial * Added patch for name_to_dev_t to support directly parsing userspace buffer Changes in v2: -------------- * Added check for null return of kstrndup in hibernate.c Thanks, Sebastian

10 years, 10 months

[PATCH REPOST 0/5] armv7 BE kvm support

by Victor Kamensky

[repost: adding kvmarm mailing list as per Christoffer's request] Hi Guys, Here is series that enables KVM support for V7 big endian kernels. Mostly it deals with BE KVM host support. Marc Zyngier showed before with his patches how BE guest could run on top LE host. With these patches BE guest runs on top of BE host. If Marc's kvmtool is used with few additional changes I tested that BE host could run LE guest. Also I verified that there were no regressions in BE guest on top of LE host case. Note that posted series covers only kernel side changes. The changes were tested inside of bigger setup with additional changes in qemu and kvmtool. I will post those changes separately in proper aliases but for completeness sake Appendix A gives pointers to git repositories and branches with all needed changes. Please note first patch is not related to BE KVM per se. I've run into an issue of conflicting 'push' identifier use while trying to include assembler.h into KVM .S files. Details of an issue I observed covered in Appendix B. The first patch is my take on solving it. Victor Kamensky (5): ARM: kvm: replace push and pop with stdmb and ldmia instrs to enable assembler.h inclusion ARM: fix KVM assembler files to work in BE case ARM: kvm one_reg coproc set and get BE fixes ARM: kvm vgic mmio should return data in BE format in BE case ARM: kvm MMIO support BE host running LE code arch/arm/include/asm/assembler.h | 7 +++ arch/arm/include/asm/kvm_asm.h | 4 +- arch/arm/include/asm/kvm_emulate.h | 22 +++++++-- arch/arm/kvm/coproc.c | 94 ++++++++++++++++++++++++++++---------- arch/arm/kvm/init.S | 7 ++- arch/arm/kvm/interrupts.S | 50 +++++++++++--------- arch/arm/kvm/interrupts_head.S | 61 +++++++++++++++---------- virt/kvm/arm/vgic.c | 4 +- 8 files changed, 168 insertions(+), 81 deletions(-) -- 1.8.1.4 Thanks, Victor Appendix A: Testing and Full Setup Description ---------------------------------------------- I) No mixed mode setup - i.e BE guest on BE host; and LE guest on LE host tested to make sure no regressions. KVM host and guest kernels: TC2 on top of Linus 3.13-rc4 (this patch series): git: git://git.linaro.org/people/victor.kamensky/linux-linaro-tracking-be.git branch: armv7be-kvm-3.13-rc4 TC2 and Arndale on top of Linaro BE tree: git: git://git.linaro.org/people/victor.kamensky/linux-linaro-tracking-be.git branch: llct-be-20131216-kvm - TC1 kernels used as guests qemu: git: git://git.linaro.org/people/victor.kamensky/qemu-be.git branch: armv7be-v1 description: changes to run qemu on armeb target; and other changes to work with be image on top of be host kvmtool: git: git://git.linaro.org/people/victor.kamensky/linux-linaro-tracking-be.git branch: kvmtool-armv7be-v1 desciption: minimal changes to build kvmtool for armeb target; and tiny change with virtio magic II) Mixed mode setup all possible combinations within V7 (LE guest on BE host; BE guest on LE host as Marc's setup tested to make sure no regressions) only with kvmtool. This work is based on Marc Zyngier's work that made BE guest to run on top of LE host. For this setup special version of kvmtool should be used and in addition I had to apply patch to guest kernel that would switch reading virtio configs reads to be LE only, that is made on top of previous Rusty Russell's changes. Effectively I just had to do very minor addition to make LE guest to work on BE host, most of heavy lifting was done before by Marc. KVM host kernels: as in previous setup Guest TC1 kernels with LE virtio config patch: git: git://git.linaro.org/people/victor.kamensky/linux-linaro-tracking-be.git branch: virtio-leconfig-3.13-rc4 kvmtool: git: git://git.linaro.org/people/victor.kamensky/linux-linaro-tracking-be.git branch: kvmtool-mixed-v1 description: based on git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git branch kvm-arm64/kvmtool-be-on-le; adds missing include fix; above armeb target build patches; and one fix related to BE mode qemu: git: git://git.linaro.org/people/victor.kamensky/qemu-be.git branch: armv7be-leconfig-v1 description: change virtio-blk that so qemu could work with guest image where virtio leconfig is made; note it does not work in mixed mode; to do so qemu would need bunch of similar changes that Marc did in kvmtool Appendix B: kvm asm file and asm/assembler.h file issue ------------------------------------------------------- diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S index ddc1553..5d3b511 100644 --- a/arch/arm/kvm/interrupts.S +++ b/arch/arm/kvm/interrupts.S @@ -25,6 +25,7 @@ #include <asm/kvm_asm.h> #include <asm/kvm_arm.h> #include <asm/vfpmacros.h> +#include <asm/assembler.h> #include "interrupts_head.S" .text produce the following compilation errors: /run/media/kamensky/wd/linaro/linux-linaro-core-tracking/092913/linux-linaro-tracking-be/arch/arm/kvm/interrupts.S: Assembler messages: /run/media/kamensky/wd/linaro/linux-linaro-core-tracking/092913/linux-linaro-tracking-be/arch/arm/kvm/interrupts.S:51: Error: ARM register expected -- `lsr {r2,r3}' /run/media/kamensky/wd/linaro/linux-linaro-core-tracking/092913/linux-linaro-tracking-be/arch/arm/kvm/interrupts.S:100: Error: ARM register expected -- `lsr {r2}' /run/media/kamensky/wd/linaro/linux-linaro-core-tracking/092913/linux-linaro-tracking-be/arch/arm/kvm/interrupts.S:100: Error: ARM register expected -- `lsr {r4-r12}'

10 years, 11 months

[discussion] simpler load balance in scheduler

by Alex Shi

Paul & Vincent & Morten, The following rough idea get during this KS. I want to have internal review before send to LKML. Would you like to give some comments? ========================== 1, Current scheduler load balance is bottom-up mode, each CPU need initiate the balance by self. Like in a integrate computer system, it has smt/core/cpu/numa, 4 level scheduler domains. If there is just 2 tasks in whole system that both running on cpu0. Current load balance need to pull task to another smt in smt domain, then pull task to another core, then pull task to another cpu, finally pull task to another numa. Totally it is need 4 times task moving to get system balance. Generally, the task moving complexity is O(nm log n), n := nr_cpus, m := nr_tasks PeterZ has a excellent summary and explanation for this in kernel/sched/fair.c:4605 Another weakness of current LB is that every cpu need to get the other cpus' load info repeatedly and try to figure out busiest sched group/queue on every sched domain level. but may not conduct a task moving, one of reasons is that cpu can only pull task, not pushing. 2, Consider huge cost of task moving: CS, tlb/cache refill, and the useless remote cpu load info getting. If we can have better solution for load balance, like reduce the balance times to. O(m) m := nr_tasks It will be a great win on performance. like above example, we can move task from cpu0 direct to another numa. that only need 1 task moving, save 3 CS and tlb/cache refill. To get this point, a rough idea is changing the load balance behaviour to top-down mode. Say let each of cpu report self load status on per-cpu memory. And a baby-sitter in system to collect these cpus load info, then decide how to move task centralize, finally send IPI to each hungry cpu to let them pull load quota from appointed cpus. Like in above example, the baby-sitter will fetch each cpus' load info, then send a pull task IPI to let a cpu in another numa pull one task from cpu0. So in the task pulling, we still just involved 2 cpus, can reuse move_tasks functions. BTW, the baby-sitter can care all kind of balance, regular balance, idle balance, wake up balance. 3, One of concern of top-down mode is that baby-sitter need remote access cpu load info on top domain level every times. But the fact is current load balance also need to get remote cpu load info for top level domain balance. and more worse, such remote accessing maybe useless. -- since there is just one thread reading the info, no competitor writer, Paul, do you think it is worthy concern? BTW, to reduce unnecessary remote info fetching, we can use current idle_cpus_mask in nohz, we just skip the idle cpu in this cpumask simply. 4, From power saving POV, top-down give the whole system cpu topology info directly. So beside the CS reducing, it can reduce the idle cpu interfere by a transition task. and let idle cpu sleep better. -- Thanks Alex

10 years, 11 months

[RFC part2 PATCH 0/9] Using ACPI MADT table to initialise SMP and GIC

by Hanjun Guo

This patch set is based on part1 "Make ACPI core running on ARM64" patch set. After we can get the ACPI tables from UEFI, we can use these tables to initialise the system now. GIC (means GIC cpu interface) structure and GIC distributor structure in MADT table contains the information of GIC cpu interface base address and GIC distributor base address, which can be used to initialise GIC. Further more, parked address in GIC structure can be used as cpu release address for spin table SMP initialisation. This patch set use these information to init SMP and GIC. Please refer to chapter 5.2.12.14/15 of ACPI 5.0 spec for GIC and GIC distributor structure information. Amit Daniel Kachhap (1): irqdomain: Add a new API irq_create_acpi_mapping() Hanjun Guo (8): ARM64 / ACPI: Implement core functions for parsing MADT table ARM64 / ACPI: Prefill cpu possible/present maps and map logical cpu id to APIC id ARM64 / ACPI: Introduce map_gic_id() to get apic id from MADT or _MAT method ARM64 / ACPI: Use Parked Address in GIC structure for spin table SMP initialisation ACPI: Define ACPI_IRQ_MODEL_GIC needed for arm Irqchip / gic: Set as default domain so we can access from ACPI ACPI / ARM64: Update acpi_register_gsi to register with the core IRQ subsystem ACPI / GIC: Initialize GIC using the information in MADT arch/arm64/include/asm/acpi.h | 16 +- arch/arm64/kernel/irq.c | 5 + arch/arm64/kernel/setup.c | 2 + arch/arm64/kernel/smp.c | 2 + arch/arm64/kernel/smp_spin_table.c | 16 +- drivers/acpi/bus.c | 3 + drivers/acpi/plat/arm-core.c | 397 +++++++++++++++++++++++++++++++++++- drivers/acpi/processor_core.c | 26 +++ drivers/acpi/tables.c | 21 ++ drivers/irqchip/irq-gic.c | 7 + include/linux/acpi.h | 9 + kernel/irq/irqdomain.c | 27 +++ 12 files changed, 521 insertions(+), 10 deletions(-) -- 1.7.9.5

10 years, 11 months

[PATCH v4 0/3] perf: add AARCH64 arch support

by Jean Pihet

Add AARCH64 specific support. This includes the following: - AARCH64 perf registers definition and hooks, - compat mode registers use, i.e. profiling a 32-bit binary on a 64-bit system, - unwinding using the dwarf information from the .debug_frame section of the ELF binary; only in 64-bit mode, - unwinding using the frame pointer information; in 64-bit and compat modes. ToDo: - add support for unwinding using the dwarf information in compat mode. This requires some changes to the libunwind code. Tested on ARMv7 and ARMv8 platforms. The compat mode has been tested on ARMv8 using statically built 32-bit binaries. Jean Pihet (3): ARM64: perf: add support for perf registers API ARM64: perf: wire up perf_regs and unwind support ARM64: perf: add support for frame pointer unwinding in compat mode arch/arm64/Kconfig | 2 + arch/arm64/include/asm/ptrace.h | 1 + arch/arm64/include/uapi/asm/Kbuild | 1 + arch/arm64/include/uapi/asm/perf_regs.h | 40 ++++++++++++++ arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/perf_event.c | 75 +++++++++++++++++++++++--- arch/arm64/kernel/perf_regs.c | 44 ++++++++++++++++ tools/perf/arch/arm64/Makefile | 7 +++ tools/perf/arch/arm64/include/perf_regs.h | 88 +++++++++++++++++++++++++++++++ tools/perf/arch/arm64/util/dwarf-regs.c | 80 ++++++++++++++++++++++++++++ tools/perf/arch/arm64/util/unwind.c | 82 ++++++++++++++++++++++++++++ tools/perf/config/Makefile | 8 ++- 12 files changed, 420 insertions(+), 9 deletions(-) create mode 100644 arch/arm64/include/uapi/asm/perf_regs.h create mode 100644 arch/arm64/kernel/perf_regs.c create mode 100644 tools/perf/arch/arm64/Makefile create mode 100644 tools/perf/arch/arm64/include/perf_regs.h create mode 100644 tools/perf/arch/arm64/util/dwarf-regs.c create mode 100644 tools/perf/arch/arm64/util/unwind.c -- 1.7.11.7

10 years, 11 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel December 2013