Re: [PATCH v2 10/11] powerpc/perf: add kconfig option for hypervisor provided counters
On Fri, 2014-02-14 at 16:25 -0800, Cody P Schafer wrote: > On Fri, Feb 14, 2014 at 04:32:13PM -0600, Scott Wood wrote: > > On Fri, 2014-02-14 at 14:02 -0800, Cody P Schafer wrote: > > > diff --git a/arch/powerpc/platforms/Kconfig.cputype > > > b/arch/powerpc/platforms/Kconfig.cputype > > > index 434fda3..dcc67cd 100644 > > > --- a/arch/powerpc/platforms/Kconfig.cputype > > > +++ b/arch/powerpc/platforms/Kconfig.cputype > > > @@ -364,6 +364,12 @@ config PPC_PERF_CTRS > > > help > > > This enables the powerpc-specific perf_event back-end. > > > > > > +config HV_PERF_CTRS > > > + def_bool y > > > + depends on PERF_EVENTS && PPC_HAVE_PMU_SUPPORT > > > + help > > > + Enable access to perf counters provided by the hypervisor > > > > Please don't add default-y stuff that is platform-specific, and > > definitely point out that platform dependency in the config description > > -- I have to look elsewhere in the patchset to determine that this is > > for "Power Hypervisor". PPC_HAVE_PMU_SUPPORT is enabled by all 6xx > > builds, even for hardware like e300 that doesn't have PMU at all (it has > > the FSL embedded perfmon instead), much less this hv interface. > > > > And yes, PPC_PERF_CTRS has the same problem and should be fixed. :-) > > Yep, I just based this one on what PPC_PERF_CTRS was doing. > > How about the following: > > +config HV_PERF_CTRS > + bool "Perf Hypervisor supplied counters" "Support for Hypervisor supplied PMU events (24x7 & GPCI)" ? > + default y > + depends on PERF_EVENTS && PPC_HAVE_PMU_SUPPORT && PPC_PSERIES I think you just want: depends on PERF_EVENTS && PPC_PSERIES Because you're adding two completely new PMUs, they're not a "struct power_pmu" backend for the existing powerpc PMU implementation. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 2/3] topology: support node_numa_mem() for determining the fallback node
On Wed, Feb 12, 2014 at 10:51:37PM -0800, Nishanth Aravamudan wrote: > Hi Joonsoo, > Also, given that only ia64 and (hopefuly soon) ppc64 can set > CONFIG_HAVE_MEMORYLESS_NODES, does that mean x86_64 can't have > memoryless nodes present? Even with fakenuma? Just curious. I don't know, because I'm not expert on NUMA system :) At first glance, fakenuma can't be used for testing CONFIG_HAVE_MEMORYLESS_NODES. Maybe some modification is needed. Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 2/3] topology: support node_numa_mem() for determining the fallback node
On Wed, Feb 12, 2014 at 04:16:11PM -0600, Christoph Lameter wrote:
> Here is another patch with some fixes. The additional logic is only
> compiled in if CONFIG_HAVE_MEMORYLESS_NODES is set.
>
> Subject: slub: Memoryless node support
>
> Support memoryless nodes by tracking which allocations are failing.
I still don't understand why this tracking is needed.
All we need for allcation targeted to memoryless node is to fallback proper
node, that it, numa_mem_id() node of targeted node. My previous patch
implements it and use proper fallback node on every allocation code path.
Why this tracking is needed? Please elaborate more on this.
> Allocations targeted to the nodes without memory fall back to the
> current available per cpu objects and if that is not available will
> create a new slab using the page allocator to fallback from the
> memoryless node to some other node.
>
> Signed-off-by: Christoph Lameter
>
> @@ -1722,7 +1738,7 @@ static void *get_partial(struct kmem_cac
> struct kmem_cache_cpu *c)
> {
> void *object;
> - int searchnode = (node == NUMA_NO_NODE) ? numa_node_id() : node;
> + int searchnode = (node == NUMA_NO_NODE) ? numa_mem_id() : node;
>
> object = get_partial_node(s, get_node(s, searchnode), c, flags);
> if (object || node != NUMA_NO_NODE)
This isn't enough.
Consider that allcation targeted to memoryless node.
get_partial_node() always fails even if there are some partial slab on
memoryless node's neareast node.
We should fallback to some proper node in this case, since there is no slab
on memoryless node.
Thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here are some more powerpc fixes for 3.14 The main one is a nasty issue with the NUMA balancing support which requires a small generic change and the addition of a new accessor to set _PAGE_NUMA. Both have been reviewed and acked by Mel and Rik. The changelog should have plenty of details but basically, without this fix, we get random user segfaults and/or corruptions due to missing TLB/hash flushes. Aneesh series of 3 patches fixes it. We have some vDSO vs. perf fixes from Anton, some small EEH fixes from Gavin, a ppc32 regression vs. the stack overflow detector, and a fix for the way we handle PCIe host bridge speed settings on pseries (which is needed for proper operations of AMD graphics cards on Power8). Cheers, Ben. The following changes since commit cd15b048445d0a54f7147c35a86c5a16ef231554: powerpc/powernv: Add iommu DMA bypass support for IODA2 (2014-02-11 16:07:37 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to 66f9af83e56bfa12964d251df9d60fb571579913: powerpc/eeh: Disable EEH on reboot (2014-02-17 11:19:39 +1100) Aneesh Kumar K.V (3): powerpc/mm: Add new "set" flag argument to pte/pmd update function mm: Dirty accountable change only apply to non prot numa case mm: Use ptep/pmdp_set_numa() for updating _PAGE_NUMA bit Anton Blanchard (2): powerpc: Link VDSOs at 0x0 powerpc: Use unstripped VDSO image for more accurate profiling data Gavin Shan (3): powerpc/powernv: Rework EEH reset powerpc/eeh: Cleanup on eeh_subsystem_enabled powerpc/eeh: Disable EEH on reboot Kevin Hao (1): powerpc: Set the correct ksp_limit on ppc32 when switching to irq stack Kleber Sacilotto de Souza (2): powerpc/pseries: Fix regression on PCI link speed powerpc/pseries: Add Gen3 definitions for PCIE link speed arch/powerpc/include/asm/eeh.h | 21 +-- arch/powerpc/include/asm/hugetlb.h | 2 +- arch/powerpc/include/asm/pgtable-ppc64.h | 26 +++ arch/powerpc/include/asm/pgtable.h | 22 arch/powerpc/include/asm/vdso.h | 6 ++--- arch/powerpc/kernel/eeh.c| 32 ++- arch/powerpc/kernel/misc_32.S| 5 +++- arch/powerpc/kernel/vdso32/vdso32_wrapper.S | 2 +- arch/powerpc/kernel/vdso64/vdso64_wrapper.S | 2 +- arch/powerpc/mm/pgtable_64.c | 12 + arch/powerpc/mm/subpage-prot.c | 2 +- arch/powerpc/platforms/powernv/eeh-ioda.c| 32 +-- arch/powerpc/platforms/powernv/eeh-powernv.c | 2 +- arch/powerpc/platforms/pseries/eeh_pseries.c | 2 +- arch/powerpc/platforms/pseries/pci.c | 22 +++- include/asm-generic/pgtable.h| 39 mm/huge_memory.c | 9 ++- mm/mprotect.c| 25 ++ 18 files changed, 172 insertions(+), 91 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] powerpc/pseries: Report in kernel device tree update to drmgr
On Fri, 2014-01-31 at 15:58 -0800, Tyrel Datwyler wrote:
> Traditionally it has been drmgr's responsibilty to update the device tree
> through the /proc/ppc64/ofdt interface after a suspend/resume operation.
> This patchset however has modified suspend/resume ops to preform that update
> entirely in the kernel during the resume. Therefore, a mechanism is required
> for drmgr to determine who is responsible for the update. This patch adds a
> show function to the "hibernate" attribute that returns 1 if the kernel
> updates the device tree after the resume and 0 if drmgr is responsible.
This is not right.
We cannot change the kernel behaviour in a way that is incompatible with
existing userspace, and unless you can explain me why that is not the
case, it feels like this patch set does just that
What happens if you have an older drmgr which still does the update
itself ?
You can't just change user visible behaviours and interface without at
least explaining why it's ok to do so at the very least (and ensuring
that of course) without breaking existing userspace.
Now it's possible that the double update caused by this series is
harmless, in which case please explain it in the changeset, I certainly
can't assume it and if it's not, you'll need some other way for drmgr to
signal the kernel to indicate it supports the new behaviour before you
enable it.
Ben.
> Signed-off-by: Tyrel Datwyler
> ---
> arch/powerpc/platforms/pseries/suspend.c | 25 -
> 1 file changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/pseries/suspend.c
> b/arch/powerpc/platforms/pseries/suspend.c
> index 1d9c580..b87b978 100644
> --- a/arch/powerpc/platforms/pseries/suspend.c
> +++ b/arch/powerpc/platforms/pseries/suspend.c
> @@ -192,7 +192,30 @@ out:
> return rc;
> }
>
> -static DEVICE_ATTR(hibernate, S_IWUSR, NULL, store_hibernate);
> +#define USER_DT_UPDATE 0
> +#define KERN_DT_UPDATE 1
> +
> +/**
> + * show_hibernate - Report device tree update responsibilty
> + * @dev: subsys root device
> + * @attr:device attribute struct
> + * @buf: buffer
> + *
> + * Report whether a device tree update is performed by the kernel after a
> + * resume, or if drmgr must coordinate the update from user space.
> + *
> + * Return value:
> + * 0 if drmgr is to initiate update, and 1 otherwise
> + **/
> +static ssize_t show_hibernate(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + return sprintf(buf, "%d\n", KERN_DT_UPDATE);
> +}
> +
> +static DEVICE_ATTR(hibernate, S_IWUSR | S_IRUGO,
> +show_hibernate, store_hibernate);
>
> static struct bus_type suspend_subsys = {
> .name = "power",
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Anyone using SysRQ key sequences on console serial port ?
On Fri, Feb 14, 2014 at 3:42 PM, John Donnelly wrote: > Hi, > > I tried using the SysRq hotkey sequence on a serial console - > 3.11.0-5-powerpc-e500mc system, by issuing a " break " and the system > immediately wedges after displaying "SysRQ : HELP : " using both "Putty" and > "Teraterm" terminal emulators. I know the system is dead because my ssh > sessions stopped too. Yes it does work -- or at least it _did_ work. Make sure your dts has an entry compatible = "fsl,ns16550", "ns16550"; since that enables a workaround I'd added for a hardware errata relating to sending breaks over the serial console. What you describe above makes me think you aren't getting the workaround enabled. Paul. -- > > http://en.wikipedia.org/wiki/Magic_SysRq_key . > > > > > -- > > Regards, > John. > > -- > > o Energy-efficiency is #1 reason data centers look to expand. -- Digital > Realty Trust > o Green Data Centers spending to increase 300% worldwide by 2016. -- Pike > Research > o Data Centers have become as vital to the functioni > ng of society as power stations. -- The Economist > > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
