Re: use of BAT before taking over the MMU
> On the prom boot path, with the firmware supposed to > be managing the MMU, there is a case where: > > 1. Linux changes some BAT registers. > 2. Bits 0x0070 are/become set in the MSR. > 3. Linux takes an MMU fault. > 4. The firmware handles it. > > AFAIK, you can't expect the firmware to leave the BAT alone. > If the firmware provides mapping services by using the BAT > as a software-filled TLB, Linux's BAT changes may be lost. > > You also can't expect that your BAT changes will not conflict > with mappings that the firmware uses for itself. The firmware > might write to your new BAT mapping, relying on those virtual > addresses to be something else entirely. The PowerPC OF binding requires the firmware to save and restore the BATs on entry to / exit from the firmware. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc44x - how do i optimize driver for tlb hits
On Sun, 2010-10-03 at 14:13 -0500, Ayman El-Khashab wrote: > On Sat, Sep 25, 2010 at 08:11:04AM +1000, Benjamin Herrenschmidt wrote: > > On Fri, 2010-09-24 at 08:08 -0500, Ayman El-Khashab wrote: > > > > > > I suppose another option is to to use the kernel profiling option I > > > always see but have never used. Is that a viable option to figure out > > > what is happening here? > > > > With perf and stochastic sampling ? If you sample fast enough... but > > you'll mostly point to your routine I suppose... though it might tell > > you statistically where in your code, which -might- help. > > > > Thanks I didn't end up profiling it b/c we found the biggest culprit. > Basically we were mapping this memory in kernel space and as long as we > did that ONLY everything was ok. But then we would mmap the physical > addresses into user space. Using MAP_SHARED made it extremely slow. > Using MAP_PRIVATE made it very fast. So it works, but why is MAP_SHARED > that much slower? I don't see any reason off hand why this would be the case. Can you inspect the content of the TLB with either xmon or whatever HW debugger you may have at hand and show me what difference you have between an entry for your workload coming from MAP_SHARED vs. one coming from MAP_PRIVATE ? > The other optimization was a change in the algorithm to take advantage > of the L2 prefetching. Since we were operating on many simultaneous > streams it seems that the cache performance was not good. Cheers, Ben. > thanks > ame ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc44x - how do i optimize driver for tlb hits
On Sat, Sep 25, 2010 at 08:11:04AM +1000, Benjamin Herrenschmidt wrote: > On Fri, 2010-09-24 at 08:08 -0500, Ayman El-Khashab wrote: > > > > I suppose another option is to to use the kernel profiling option I > > always see but have never used. Is that a viable option to figure out > > what is happening here? > > With perf and stochastic sampling ? If you sample fast enough... but > you'll mostly point to your routine I suppose... though it might tell > you statistically where in your code, which -might- help. > Thanks I didn't end up profiling it b/c we found the biggest culprit. Basically we were mapping this memory in kernel space and as long as we did that ONLY everything was ok. But then we would mmap the physical addresses into user space. Using MAP_SHARED made it extremely slow. Using MAP_PRIVATE made it very fast. So it works, but why is MAP_SHARED that much slower? The other optimization was a change in the algorithm to take advantage of the L2 prefetching. Since we were operating on many simultaneous streams it seems that the cache performance was not good. thanks ame ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/9] v3 Define memory_block_size_bytes for powerpc/pseries
* Dave Hansen [2010-10-03 11:11:01]: > On Sun, 2010-10-03 at 13:07 -0500, Robin Holt wrote: > > On Sun, Oct 03, 2010 at 11:25:00PM +0530, Balbir Singh wrote: > > > * Nathan Fontenot [2010-10-01 13:35:54]: > > > > > > > Define a version of memory_block_size_bytes() for powerpc/pseries such > > > > that > > > > a memory block spans an entire lmb. > > > > > > I hope I am not missing anything obvious, but why not just call it > > > lmb_size, why do we need memblock_size? > > > > > > Is lmb_size == memblock_size after your changes true for all > > > platforms? > > > > What is an lmb? I don't recall anything like lmb being referred to in > > the rest of the kernel. > > Heh. It's the OpenFirmware name for a Logical Memory Block. Basically > what we use to determine the SECTION_SIZE on powerpc. Probably not the > best terminology to use elsewhere in the kernel. Agreed for the kernel, this patch was for powerpc/pseries, hence was checking in this context. -- Three Cheers, Balbir ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/9] v3 Define memory_block_size_bytes for powerpc/pseries
On Sun, 2010-10-03 at 13:07 -0500, Robin Holt wrote: > On Sun, Oct 03, 2010 at 11:25:00PM +0530, Balbir Singh wrote: > > * Nathan Fontenot [2010-10-01 13:35:54]: > > > > > Define a version of memory_block_size_bytes() for powerpc/pseries such > > > that > > > a memory block spans an entire lmb. > > > > I hope I am not missing anything obvious, but why not just call it > > lmb_size, why do we need memblock_size? > > > > Is lmb_size == memblock_size after your changes true for all > > platforms? > > What is an lmb? I don't recall anything like lmb being referred to in > the rest of the kernel. Heh. It's the OpenFirmware name for a Logical Memory Block. Basically what we use to determine the SECTION_SIZE on powerpc. Probably not the best terminology to use elsewhere in the kernel. -- Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/9] v3 Define memory_block_size_bytes for powerpc/pseries
On Sun, Oct 03, 2010 at 11:25:00PM +0530, Balbir Singh wrote: > * Nathan Fontenot [2010-10-01 13:35:54]: > > > Define a version of memory_block_size_bytes() for powerpc/pseries such that > > a memory block spans an entire lmb. > > I hope I am not missing anything obvious, but why not just call it > lmb_size, why do we need memblock_size? > > Is lmb_size == memblock_size after your changes true for all > platforms? What is an lmb? I don't recall anything like lmb being referred to in the rest of the kernel. Robin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/9] v3 Define memory_block_size_bytes for powerpc/pseries
* Nathan Fontenot [2010-10-01 13:35:54]:
> Define a version of memory_block_size_bytes() for powerpc/pseries such that
> a memory block spans an entire lmb.
I hope I am not missing anything obvious, but why not just call it
lmb_size, why do we need memblock_size?
Is lmb_size == memblock_size after your changes true for all
platforms?
>
> Signed-off-by: Nathan Fontenot
>
> ---
> arch/powerpc/platforms/pseries/hotplug-memory.c | 66
> +++-
> 1 file changed, 53 insertions(+), 13 deletions(-)
>
> Index: linux-next/arch/powerpc/platforms/pseries/hotplug-memory.c
> ===
> --- linux-next.orig/arch/powerpc/platforms/pseries/hotplug-memory.c
> 2010-09-30 14:44:37.0 -0500
> +++ linux-next/arch/powerpc/platforms/pseries/hotplug-memory.c
> 2010-09-30 14:47:04.0 -0500
> @@ -17,6 +17,54 @@
> #include
> #include
>
> +static unsigned long get_memblock_size(void)
> +{
> + struct device_node *np;
> + unsigned int memblock_size = 0;
> +
> + np = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
> + if (np) {
> + const unsigned long *size;
> +
> + size = of_get_property(np, "ibm,lmb-size", NULL);
> + memblock_size = size ? *size : 0;
> +
> + of_node_put(np);
> + } else {
> + unsigned int memzero_size = 0;
> + const unsigned int *regs;
> +
> + np = of_find_node_by_path("/mem...@0");
> + if (np) {
> + regs = of_get_property(np, "reg", NULL);
> + memzero_size = regs ? regs[3] : 0;
> + of_node_put(np);
> + }
> +
> + if (memzero_size) {
> + /* We now know the size of mem...@0, use this to find
> + * the first memoryblock and get its size.
> + */
Nit: comment style is not correct
> + char buf[64];
> +
> + sprintf(buf, "/mem...@%x", memzero_size);
> + np = of_find_node_by_path(buf);
> + if (np) {
> + regs = of_get_property(np, "reg", NULL);
> + memblock_size = regs ? regs[3] : 0;
> + of_node_put(np);
> + }
> + }
> + }
> +
> + return memblock_size;
> +}
> +
> +unsigned long memory_block_size_bytes(void)
> +{
> + return get_memblock_size();
> +}
> +
> static int pseries_remove_memblock(unsigned long base, unsigned int
> memblock_size)
> {
> unsigned long start, start_pfn;
> @@ -127,30 +175,22 @@
>
> static int pseries_drconf_memory(unsigned long *base, unsigned int action)
> {
> - struct device_node *np;
> - const unsigned long *lmb_size;
> + unsigned long memblock_size;
> int rc;
>
> - np = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
> - if (!np)
> + memblock_size = get_memblock_size();
> + if (!memblock_size)
> return -EINVAL;
>
> - lmb_size = of_get_property(np, "ibm,lmb-size", NULL);
> - if (!lmb_size) {
> - of_node_put(np);
> - return -EINVAL;
> - }
> -
> if (action == PSERIES_DRCONF_MEM_ADD) {
> - rc = memblock_add(*base, *lmb_size);
> + rc = memblock_add(*base, memblock_size);
> rc = (rc < 0) ? -EINVAL : 0;
> } else if (action == PSERIES_DRCONF_MEM_REMOVE) {
> - rc = pseries_remove_memblock(*base, *lmb_size);
> + rc = pseries_remove_memblock(*base, memblock_size);
> } else {
> rc = -EINVAL;
> }
>
> - of_node_put(np);
> return rc;
> }
>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org
>
--
Three Cheers,
Balbir
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/8] v2 De-Couple sysfs memory directories from memory sections
On 09/29/2010 02:37 PM, Greg KH wrote: >> > Thankfully things like rpm, hald, and other miscellaneous commands scan >> > that information. >> >> Really? Why? Why would rpm care about this? hald is dead now so we >> don't need to worry about that anymore, > > That's not what compatiblity means. We can't just support > latest-and-greatest userspace on latest-and-greatest kernels. Oh, I know that, that's not what I was getting at at all here, sorry if it came across that way. I wanted to know so we could go fix programs that are mucking around in these files, as odds are, the shouldn't be doing that in the first place. Like rpm, why would it matter what the memory in the system looks like? I see, thanks. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
