* [PATCH 1/1] powerpc: Add kdump support to Collaborative Memory Manager
From: Brian King @ 2009-10-19 15:51 UTC (permalink / raw)
To: benh; +Cc: brking, linuxppc-dev
When running Active Memory Sharing, the Collaborative Memory Manager (CMM)
may mark some pages as "loaned" with the hypervisor. Periodically, the
CMM will query the hypervisor for a loan request, which is a single signed
value. When kexec'ing into a kdump kernel, the CMM driver in the kdump
kernel is not aware of the pages the previous kernel had marked as "loaned",
so the hypervisor and the CMM driver are out of sync. Fix the CMM driver
to handle this scenario by ignoring requests to decrease the number of loaned
pages if we don't think we have any pages loaned. Pages that are marked as
"loaned" which are not in the balloon will automatically get switched to "active"
the next time we touch the page. This also fixes the case where totalram_pages
is smaller than min_mem_mb, which can occur during kdump.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/Kconfig | 2 +-
arch/powerpc/platforms/pseries/cmm.c | 29 +++++++++++++++++++----------
2 files changed, 20 insertions(+), 11 deletions(-)
diff -puN arch/powerpc/platforms/pseries/cmm.c~powerpc_cmm_fix_kdump arch/powerpc/platforms/pseries/cmm.c
--- linux-2.6/arch/powerpc/platforms/pseries/cmm.c~powerpc_cmm_fix_kdump 2009-09-24 16:35:00.000000000 -0500
+++ linux-2.6-bjking1/arch/powerpc/platforms/pseries/cmm.c 2009-09-25 10:24:19.000000000 -0500
@@ -229,8 +229,9 @@ static void cmm_get_mpp(void)
{
int rc;
struct hvcall_mpp_data mpp_data;
- unsigned long active_pages_target;
- signed long page_loan_request;
+ signed long active_pages_target, page_loan_request, target;
+ signed long total_pages = totalram_pages + loaned_pages;
+ signed long min_mem_pages = (min_mem_mb * 1024 * 1024) / PAGE_SIZE;
rc = h_get_mpp(&mpp_data);
@@ -238,17 +239,25 @@ static void cmm_get_mpp(void)
return;
page_loan_request = div_s64((s64)mpp_data.loan_request, PAGE_SIZE);
- loaned_pages_target = page_loan_request + loaned_pages;
- if (loaned_pages_target > oom_freed_pages)
- loaned_pages_target -= oom_freed_pages;
+ target = page_loan_request + (signed long)loaned_pages;
+
+ if (target < 0 || total_pages < min_mem_pages)
+ target = 0;
+
+ if (target > oom_freed_pages)
+ target -= oom_freed_pages;
else
- loaned_pages_target = 0;
+ target = 0;
+
+ active_pages_target = total_pages - target;
+
+ if (min_mem_pages > active_pages_target)
+ target = total_pages - min_mem_pages;
- active_pages_target = totalram_pages + loaned_pages - loaned_pages_target;
+ if (target < 0)
+ target = 0;
- if ((min_mem_mb * 1024 * 1024) > (active_pages_target * PAGE_SIZE))
- loaned_pages_target = totalram_pages + loaned_pages -
- ((min_mem_mb * 1024 * 1024) / PAGE_SIZE);
+ loaned_pages_target = target;
cmm_dbg("delta = %ld, loaned = %lu, target = %lu, oom = %lu, totalram = %lu\n",
page_loan_request, loaned_pages, loaned_pages_target,
diff -puN arch/powerpc/platforms/pseries/Kconfig~powerpc_cmm_fix_kdump arch/powerpc/platforms/pseries/Kconfig
--- linux-2.6/arch/powerpc/platforms/pseries/Kconfig~powerpc_cmm_fix_kdump 2009-09-24 16:35:00.000000000 -0500
+++ linux-2.6-bjking1/arch/powerpc/platforms/pseries/Kconfig 2009-09-24 16:35:00.000000000 -0500
@@ -59,7 +59,7 @@ config PPC_SMLPAR
config CMM
tristate "Collaborative memory management"
- depends on PPC_SMLPAR && !CRASH_DUMP
+ depends on PPC_SMLPAR
default y
help
Select this option, if you want to enable the kernel interface
_
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Scott Wood @ 2009-10-19 15:40 UTC (permalink / raw)
To: Felix Radensky
Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org,
Adrian Hunter
In-Reply-To: <4ADAE205.7070106@embedded-sol.com>
On Sun, Oct 18, 2009 at 11:38:13AM +0200, Felix Radensky wrote:
> Hi, Scott
>
> Scott Wood wrote:
>> On Fri, Oct 16, 2009 at 07:01:43AM +0200, Felix Radensky wrote:
>>> Thanks for confirmation. So the real problem is eLBC ?
>>> What happens if I access other devices on eLBC (e.g. FPGA)
>>> simultaneously with NAND or NOR ?
>>
>> AFAICT, the problem is NAND being accessed simultaneously with anything else
>> on the eLBC (at least GPCM -- not sure about UPM). Instead of delaying the
>> memory-like transaction until the NAND special operation has completed, it
>> seems to just abort the NAND operation.
>>
>> eLBC can't really tell the difference whether you've got NOR or FPGA hooked
>> up to a GPCM chip select, so the problem should still apply.
>>
>
> Can you please provide some code example of synchronizing GPCM and NAND ?
I don't have any. It's something that would have to be written.
-Scott
^ permalink raw reply
* Acceleration for map_copy_from on powerpc 512x
From: Fortini Matteo @ 2009-10-19 7:52 UTC (permalink / raw)
To: linux-ppc list
Hi,
I'm working on a powerpc (PPC512x) embedded Linux product, and while I
was trying to improve boot time, I found I could exploit the hw in order
to speed up reading from NOR flashes.
The Linux/mtd version we're using is 2.6.24.6+Freescale patches.
Basically, I needed to hack the map_copy_from, which for my arch and
uncached areas translates to a memcpy, in order to use the SCLPC FIFO,
with a performance benefit of >2x on aligned multiple of 32Bytes transfers.
I didn't find a cleaner way than just #ifdef'ing the map_copy_from call
and substitute with my call on relevant cases. I wonder if there is a
cleaner way.
And yes, as soon as I've cleaned up the code a little bit, I will
definitely post a patch about it.
Moreover: a huge benefit would come from exploiting DMA on these
transfers, but I found I'm in_atomic while doing map_copy_from... is
there an alternative way of locking than just disabling preemption?
I know maybe a newer kernel has already fixed it, but we're kind of
stuck with the old one since we don't have time to port all of our
device drivers to 2.6.3x
Thanks,
Matteo
^ permalink raw reply
* Re: [PATCH 3/3] powerpc perf_event: Add alignment-faults and emulation-faults software events
From: Ingo Molnar @ 2009-10-19 7:25 UTC (permalink / raw)
To: Anton Blanchard; +Cc: paulus, a.p.zijlstra, linux-kernel, linuxppc-dev
In-Reply-To: <20091018111300.GM4808@kryten>
* Anton Blanchard <anton@samba.org> wrote:
> Hook up the alignment-faults and emulation-faults events for powerpc.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
nice.
The first patch is for perf events - it would be nice if we could do the
two PowerPC changes via the perf events tree - that would speed up the
upstream availability of this new feature. Ben, what do you think?
Ingo
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: perf_event: Hide iseries_check_pending_irqs
From: Ingo Molnar @ 2009-10-19 7:23 UTC (permalink / raw)
To: Anton Blanchard; +Cc: paulus, a.p.zijlstra, linuxppc-dev
In-Reply-To: <20091018112429.GP4808@kryten>
* Anton Blanchard <anton@samba.org> wrote:
> If CONFIG_PPC_ISERIES isn't defined we end up with iseries_check_pending_irqs
> and do_work at the same address. perf ends up picking
> iseries_check_pending_irqs which creates confusing backtraces. Hide it.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Just to confirm - these 3 symbol fixes are for the PowerPC tree, not for
the perf events tree, right? There's nothing perf specific about the
fixes - kgdb, systemtap and other debugging/instrumentation frameworks
will benefit from more precise symbol generation too.
Ingo
^ permalink raw reply
* Re: MPC5121 CAN and USB
From: David Jander @ 2009-10-19 6:46 UTC (permalink / raw)
To: linuxppc-dev
Cc: Kári Davíðsson, linuxppc-dev@ozlabs.org,
Paul Gibson, Wolfgang Denk
In-Reply-To: <20091015231005.D2CE9F15432@gemini.denx.de>
On Friday 16 October 2009 01:10:05 am Wolfgang Denk wrote:
> Dear Paul,
>
> In message <26b052040910151603y8fc9b00g678d6a873083f1e7@mail.gmail.com> you
wrote:
> > > The "ltib-mpc5121ads-20090602" branch reflects the exact state of the
> > > kernel contained in the LTIB with this name (dated July 2009, despite
> > > the name; based at 2.6.24.6, i. e. 7+ kernel versions behind).
> >
> > I have diff'ed this and it is very similar to the ltib in the BSP.
> > The MBX patches may be missing though. These patches can be obtained
> > via the Freescale SDK for the OpenGL on the MPC5121e webpage.
>
> Who cares. This code is about 8 (!) kernel releases behind. Scrap
> it.
I would love to, but as it stands, this is still the best we can get for the
MPC5121e :-(
I took that branch, merged the MBX patch in from the LTIB and ported the new
NFC driver from the 'mpc512x' branch back to this one, since the original
driver is buggy.
The latest OpenGL-ES libraries and MBX drivers released are closed-source,
buggy, but stable and seem to work well if your program doesn't do the kinds
of things that make it crash.
If you know the limitations of this and can live with it, it might be
bearable... I don't have any other option :-(
Best regards,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix compile errors found by new ppc64e_defconfig
From: Benjamin Herrenschmidt @ 2009-10-19 4:24 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1255910308.4192.8.camel@concordia>
On Mon, 2009-10-19 at 10:58 +1100, Michael Ellerman wrote:
> > if (bus->self) {
> > +#ifdef CONFIG_PPC_STD_MMU_64
> > struct resource *res = bus->resource[0];
> > +#endif
> >
> > pr_debug("IO unmapping for PCI-PCI bridge %s\n",
> > pci_name(bus->self));
> 104
> 105 #ifdef CONFIG_PPC_STD_MMU_64
> 106 __flush_hash_table_range(&init_mm, res->start + _IO_BASE,
> 107 res->end + _IO_BASE + 1);
> 108 #endif
> 109 return 0;
> 110 }
>
> So just expand the ifdef around the pr_debug()?
I'd rather move the pr_debug to after the ifdef, it doesn't need to
absolutely be before the __flush_hash_* call, it's more to see in the
log whether the bus was properly unmapped when doing unplug.
Cheers,
Ben.
^ permalink raw reply
* Re: Mixing hard and soft floating point?
From: Peter Bergner @ 2009-10-19 0:57 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20091017193454.7978FF15432@gemini.denx.de>
On Sat, 2009-10-17 at 21:34 +0200, Wolfgang Denk wrote:
> Dear Joakim Tjernlund,
> > OK, but then you don't mix some libs/apps with soft and other
> > apps/libs with hard FP?
>
> No, we never tried that. Sounds scary to me.
And dangerous. Hard-float and soft-float are ABI incompatible, so you
cannot mix and match obj files and libs compiled with those two options.
They all have to be hard-float or they all have to be soft-float.
Think about a function compiled with hard-float calling a soft-float
libm routine. The hard-float routine will pass its args in via FP
regs and the soft-float lib routine will be looking for them in the
integer registers.
Peter
^ permalink raw reply
* Re: [PATCH 3/3] powerpc perf_event: Add alignment-faults and emulation-faults software events
From: Anton Blanchard @ 2009-10-19 0:42 UTC (permalink / raw)
To: Michael Ellerman; +Cc: a.p.zijlstra, linux-kernel, linuxppc-dev, paulus, mingo
In-Reply-To: <1255909805.4192.5.camel@concordia>
Hi,
> > +#define PPC_WARN_ALIGNMENT(type, regs) \
> > + do { \
> > + perf_sw_event(PERF_COUNT_SW_ALIGNMENT_FAULTS, \
> > + 1, 0, regs, regs->dar); \
> > + __PPC_WARN_EMULATED(type); \
> > + } while (0)
>
> Does that work with perfxxx configured off?
Yeah, perf_event.h defines an empty version if its configured off:
static inline void
perf_sw_event(u32 event_id, u64 nr, int nmi,
struct pt_regs *regs, u64 addr) { }
Anton
^ permalink raw reply
* Re: [PATCH] powerpc: Fix compile errors found by new ppc64e_defconfig
From: Michael Ellerman @ 2009-10-18 23:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1255712717-21221-2-git-send-email-galak@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2285 bytes --]
On Fri, 2009-10-16 at 12:05 -0500, Kumar Gala wrote:
> Fix the following 3 issues:
>
> arch/powerpc/kernel/process.c: In function 'arch_randomize_brk':
> arch/powerpc/kernel/process.c:1183: error: 'mmu_highuser_ssize' undeclared (first use in this function)
> arch/powerpc/kernel/process.c:1183: error: (Each undeclared identifier is reported only once
> arch/powerpc/kernel/process.c:1183: error: for each function it appears in.)
> arch/powerpc/kernel/process.c:1183: error: 'MMU_SEGSIZE_1T' undeclared (first use in this function)
>
> In file included from arch/powerpc/kernel/setup_64.c:60:
> arch/powerpc/include/asm/mmu-hash64.h:132: error: redefinition of 'struct mmu_psize_def'
> arch/powerpc/include/asm/mmu-hash64.h:159: error: expected identifier or '(' before numeric constant
> arch/powerpc/include/asm/mmu-hash64.h:396: error: conflicting types for 'mm_context_t'
> arch/powerpc/include/asm/mmu-book3e.h:184: error: previous declaration of 'mm_context_t' was here
>
> cc1: warnings being treated as errors
> arch/powerpc/kernel/pci_64.c: In function 'pcibios_unmap_io_space':
> arch/powerpc/kernel/pci_64.c:100: error: unused variable 'res'
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/kernel/pci_64.c | 2 ++
> arch/powerpc/kernel/process.c | 2 +-
> arch/powerpc/kernel/setup_64.c | 1 -
> 3 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
> index ba949a2..ccf56ac 100644
> --- a/arch/powerpc/kernel/pci_64.c
> +++ b/arch/powerpc/kernel/pci_64.c
> @@ -97,7 +97,9 @@ int pcibios_unmap_io_space(struct pci_bus *bus)
> * to do an appropriate TLB flush here too
> */
> if (bus->self) {
> +#ifdef CONFIG_PPC_STD_MMU_64
> struct resource *res = bus->resource[0];
> +#endif
>
> pr_debug("IO unmapping for PCI-PCI bridge %s\n",
> pci_name(bus->self));
104
105 #ifdef CONFIG_PPC_STD_MMU_64
106 __flush_hash_table_range(&init_mm, res->start + _IO_BASE,
107 res->end + _IO_BASE + 1);
108 #endif
109 return 0;
110 }
So just expand the ifdef around the pr_debug()?
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] powerpc perf_event: Add alignment-faults and emulation-faults software events
From: Michael Ellerman @ 2009-10-18 23:50 UTC (permalink / raw)
To: Anton Blanchard; +Cc: a.p.zijlstra, linux-kernel, linuxppc-dev, paulus, mingo
In-Reply-To: <20091018111300.GM4808@kryten>
[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]
On Sun, 2009-10-18 at 22:13 +1100, Anton Blanchard wrote:
> Hook up the alignment-faults and emulation-faults events for powerpc.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
>
> Index: linux.trees.git/arch/powerpc/include/asm/emulated_ops.h
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/include/asm/emulated_ops.h 2009-09-22 13:45:07.000000000 +1000
> +++ linux.trees.git/arch/powerpc/include/asm/emulated_ops.h 2009-09-22 13:45:27.000000000 +1000
> @@ -19,6 +19,7 @@
> #define _ASM_POWERPC_EMULATED_OPS_H
>
> #include <asm/atomic.h>
> +#include <linux/perf_event.h>
>
>
> #ifdef CONFIG_PPC_EMULATED_STATS
> @@ -71,7 +72,18 @@ extern void ppc_warn_emulated_print(cons
>
> #endif /* !CONFIG_PPC_EMULATED_STATS */
>
> -#define PPC_WARN_EMULATED(type, regs) __PPC_WARN_EMULATED(type)
> -#define PPC_WARN_ALIGNMENT(type, regs) __PPC_WARN_EMULATED(type)
> +#define PPC_WARN_EMULATED(type, regs) \
> + do { \
> + perf_sw_event(PERF_COUNT_SW_EMULATION_FAULTS, \
> + 1, 0, regs, 0); \
> + __PPC_WARN_EMULATED(type); \
> + } while (0)
> +
> +#define PPC_WARN_ALIGNMENT(type, regs) \
> + do { \
> + perf_sw_event(PERF_COUNT_SW_ALIGNMENT_FAULTS, \
> + 1, 0, regs, regs->dar); \
> + __PPC_WARN_EMULATED(type); \
> + } while (0)
Does that work with perfxxx configured off?
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Mixing hard and soft floating point?
From: Wolfgang Denk @ 2009-10-18 13:10 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev
In-Reply-To: <OFEFBDE7C9.DA9D5B8B-ONC1257653.003E3DC6-C1257653.003F0B37@transmode.se>
Dear Joakim Tjernlund,
In message <OFEFBDE7C9.DA9D5B8B-ONC1257653.003E3DC6-C1257653.003F0B37@transmode.se> you wrote:
>
> > If the application is really using FP instructions a lot, then there
> > is a huge difference between using soft-float and MATH_EMU; I
> > remember test cases where soft-float was faster by factors of
> > 500...1000.
>
> Ouch, I had no idea that it could be that much.
Well, consider really simple operations, like FP add or similar, and
compare the library code for the soft-FP implementationagainst the
cost for a trap into the kernel. Or even worse - a consider simple
assignment ("float x, foo; x = foo"); with soft-float: "lis 9,x@ha;
stw 3,x@l(9)" = 2 instructions, with MATH_EMU "lis 9,x@ha; stfs
1,x@l(9)" = 1 insn plus a kernel trap.
For real numbers, run a benchmark that models your real use case.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Little known fact about Middle Earth: The Hobbits had a very sophi-
sticated computer network! It was a Tolkien Ring...
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: Create PPC_WARN_ALIGNMENT to match PPC_WARN_EMULATED
From: Stephen Rothwell @ 2009-10-18 12:37 UTC (permalink / raw)
To: Anton Blanchard; +Cc: a.p.zijlstra, linux-kernel, linuxppc-dev, paulus, mingo
In-Reply-To: <20091018111126.GL4808@kryten>
[-- Attachment #1: Type: text/plain, Size: 523 bytes --]
Hi Anton,
On Sun, 18 Oct 2009 22:11:26 +1100 Anton Blanchard <anton@samba.org> wrote:
>
> @@ -66,8 +66,12 @@ extern void ppc_warn_emulated_print(cons
>
> #else /* !CONFIG_PPC_EMULATED_STATS */
>
> -#define PPC_WARN_EMULATED(type) do { } while (0)
> +#define __PPC_WARN_EMULATED(type) do { } while (0)
> +#define __PPC_WARN_ALIGNMENT(type) do { } while (0)
I think this last line is not needed?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Mixing hard and soft floating point?
From: Joakim Tjernlund @ 2009-10-18 11:28 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20091017193454.7978FF15432@gemini.denx.de>
Wolfgang Denk <wd@denx.de> wrote on 17/10/2009 21:34:54:
>
> Dear Joakim Tjernlund,
>
> In message <OFEC00B9FB.B03AA854-ONC1257652.00644350-C1257652.
> 00651551@transmode.se> you wrote:
> >
> > > Recompile and relink it with soft-fp as well. Or ask the provider to
> > > do that.
> >
> > That is what I am trying do/find out. The supplier claims that
> > it should not be a problem and is ATM unwilling to recompile the app/libs.
> > I am not convinced won't cause problems, not to mention performance degradation.
>
> If the application is really using FP instructions a lot, then there
> is a huge difference between using soft-float and MATH_EMU; I
> remember test cases where soft-float was faster by factors of
> 500...1000.
Ouch, I had no idea that it could be that much.
>
> > OK, but then you don't mix some libs/apps with soft and other
> > apps/libs with hard FP?
>
> No, we never tried that. Sounds scary to me.
Yes, it did to me too. That is why I figured I should ask on the
list.
^ permalink raw reply
* [PATCH 3/3] powerpc: perf_event: Hide iseries_check_pending_irqs
From: Anton Blanchard @ 2009-10-18 11:24 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, mingo, paulus, a.p.zijlstra
In-Reply-To: <20091018112406.GO4808@kryten>
If CONFIG_PPC_ISERIES isn't defined we end up with iseries_check_pending_irqs
and do_work at the same address. perf ends up picking
iseries_check_pending_irqs which creates confusing backtraces. Hide it.
Signed-off-by: Anton Blanchard <anton@samba.org>
--
Index: linux.trees.git/arch/powerpc/kernel/entry_64.S
===================================================================
--- linux.trees.git.orig/arch/powerpc/kernel/entry_64.S 2009-10-16 11:06:10.000000000 +1100
+++ linux.trees.git/arch/powerpc/kernel/entry_64.S 2009-10-16 11:06:28.000000000 +1100
@@ -551,7 +551,7 @@ restore:
BEGIN_FW_FTR_SECTION
ld r5,SOFTE(r1)
FW_FTR_SECTION_ELSE
- b iseries_check_pending_irqs
+ b .Liseries_check_pending_irqs
ALT_FW_FTR_SECTION_END_IFCLR(FW_FEATURE_ISERIES)
2:
TRACE_AND_RESTORE_IRQ(r5);
@@ -623,7 +623,7 @@ ALT_FW_FTR_SECTION_END_IFCLR(FW_FEATURE_
#endif /* CONFIG_PPC_BOOK3E */
-iseries_check_pending_irqs:
+.Liseries_check_pending_irqs:
#ifdef CONFIG_PPC_ISERIES
ld r5,SOFTE(r1)
cmpdi 0,r5,0
^ permalink raw reply
* [PATCH 2/3] powerpc: perf_event: Cleanup output by adding symbols
From: Anton Blanchard @ 2009-10-18 11:24 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, mingo, paulus, a.p.zijlstra
In-Reply-To: <20091018112328.GN4808@kryten>
Add some dummy symbols for the branches at 0xf00, 0xf20 and 0xf40,
otherwise hits end up in trap_0e which is confusing to the user.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux.trees.git/arch/powerpc/kernel/exceptions-64s.S
===================================================================
--- linux.trees.git.orig/arch/powerpc/kernel/exceptions-64s.S 2009-07-06 10:13:56.000000000 +1000
+++ linux.trees.git/arch/powerpc/kernel/exceptions-64s.S 2009-07-06 10:13:57.000000000 +1000
@@ -185,12 +185,15 @@
* prolog code of the PerformanceMonitor one. A little
* trickery is thus necessary
*/
+performance_monitor_pSeries_1:
. = 0xf00
b performance_monitor_pSeries
+altivec_unavailable_pSeries_1:
. = 0xf20
b altivec_unavailable_pSeries
+vsx_unavailable_pSeries_1:
. = 0xf40
b vsx_unavailable_pSeries
^ permalink raw reply
* [PATCH 1/3] powerpc: perf_event: Cleanup copy_page output by hiding setup symbol
From: Anton Blanchard @ 2009-10-18 11:23 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, mingo, paulus, a.p.zijlstra
A lot of hits in "setup" doesn't make much sense, so hide this symbol and
allow all the hits to end up in copy_4k_page.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux.trees.git/arch/powerpc/lib/copypage_64.S
===================================================================
--- linux.trees.git.orig/arch/powerpc/lib/copypage_64.S 2009-07-06 10:13:56.000000000 +1000
+++ linux.trees.git/arch/powerpc/lib/copypage_64.S 2009-07-06 10:13:57.000000000 +1000
@@ -26,11 +26,11 @@
srd r8,r5,r11
mtctr r8
-setup:
+.Lsetup:
dcbt r9,r4
dcbz r9,r3
add r9,r9,r12
- bdnz setup
+ bdnz .Lsetup
END_FTR_SECTION_IFSET(CPU_FTR_CP_USE_DCBTZ)
addi r3,r3,-8
srdi r8,r5,7 /* page is copied in 128 byte strides */
^ permalink raw reply
* [PATCH 3/3] powerpc perf_event: Add alignment-faults and emulation-faults software events
From: Anton Blanchard @ 2009-10-18 11:13 UTC (permalink / raw)
To: benh, mingo, paulus, a.p.zijlstra; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20091018111126.GL4808@kryten>
Hook up the alignment-faults and emulation-faults events for powerpc.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux.trees.git/arch/powerpc/include/asm/emulated_ops.h
===================================================================
--- linux.trees.git.orig/arch/powerpc/include/asm/emulated_ops.h 2009-09-22 13:45:07.000000000 +1000
+++ linux.trees.git/arch/powerpc/include/asm/emulated_ops.h 2009-09-22 13:45:27.000000000 +1000
@@ -19,6 +19,7 @@
#define _ASM_POWERPC_EMULATED_OPS_H
#include <asm/atomic.h>
+#include <linux/perf_event.h>
#ifdef CONFIG_PPC_EMULATED_STATS
@@ -71,7 +72,18 @@ extern void ppc_warn_emulated_print(cons
#endif /* !CONFIG_PPC_EMULATED_STATS */
-#define PPC_WARN_EMULATED(type, regs) __PPC_WARN_EMULATED(type)
-#define PPC_WARN_ALIGNMENT(type, regs) __PPC_WARN_EMULATED(type)
+#define PPC_WARN_EMULATED(type, regs) \
+ do { \
+ perf_sw_event(PERF_COUNT_SW_EMULATION_FAULTS, \
+ 1, 0, regs, 0); \
+ __PPC_WARN_EMULATED(type); \
+ } while (0)
+
+#define PPC_WARN_ALIGNMENT(type, regs) \
+ do { \
+ perf_sw_event(PERF_COUNT_SW_ALIGNMENT_FAULTS, \
+ 1, 0, regs, regs->dar); \
+ __PPC_WARN_EMULATED(type); \
+ } while (0)
#endif /* _ASM_POWERPC_EMULATED_OPS_H */
^ permalink raw reply
* [PATCH 2/3] powerpc: Create PPC_WARN_ALIGNMENT to match PPC_WARN_EMULATED
From: Anton Blanchard @ 2009-10-18 11:11 UTC (permalink / raw)
To: benh, mingo, paulus, a.p.zijlstra; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20091018110929.GK4808@kryten>
perf_event wants a separate event for alignment and emulation faults,
so create another PPC_WARN_* define. This will make it easy to hook in
perf_event at one spot.
We pass in regs which will be required for these events.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux.trees.git/arch/powerpc/include/asm/emulated_ops.h
===================================================================
--- linux.trees.git.orig/arch/powerpc/include/asm/emulated_ops.h 2009-09-01 15:11:03.000000000 +1000
+++ linux.trees.git/arch/powerpc/include/asm/emulated_ops.h 2009-09-14 09:47:23.000000000 +1000
@@ -57,7 +57,7 @@ extern u32 ppc_warn_emulated;
extern void ppc_warn_emulated_print(const char *type);
-#define PPC_WARN_EMULATED(type) \
+#define __PPC_WARN_EMULATED(type) \
do { \
atomic_inc(&ppc_emulated.type.val); \
if (ppc_warn_emulated) \
@@ -66,8 +66,12 @@ extern void ppc_warn_emulated_print(cons
#else /* !CONFIG_PPC_EMULATED_STATS */
-#define PPC_WARN_EMULATED(type) do { } while (0)
+#define __PPC_WARN_EMULATED(type) do { } while (0)
+#define __PPC_WARN_ALIGNMENT(type) do { } while (0)
#endif /* !CONFIG_PPC_EMULATED_STATS */
+#define PPC_WARN_EMULATED(type, regs) __PPC_WARN_EMULATED(type)
+#define PPC_WARN_ALIGNMENT(type, regs) __PPC_WARN_EMULATED(type)
+
#endif /* _ASM_POWERPC_EMULATED_OPS_H */
Index: linux.trees.git/arch/powerpc/kernel/align.c
===================================================================
--- linux.trees.git.orig/arch/powerpc/kernel/align.c 2009-09-01 15:11:03.000000000 +1000
+++ linux.trees.git/arch/powerpc/kernel/align.c 2009-09-14 09:47:23.000000000 +1000
@@ -732,7 +732,7 @@ int fix_alignment(struct pt_regs *regs)
#ifdef CONFIG_SPE
if ((instr >> 26) == 0x4) {
- PPC_WARN_EMULATED(spe);
+ PPC_WARN_ALIGNMENT(spe, regs);
return emulate_spe(regs, reg, instr);
}
#endif
@@ -786,7 +786,7 @@ int fix_alignment(struct pt_regs *regs)
flags |= SPLT;
nb = 8;
}
- PPC_WARN_EMULATED(vsx);
+ PPC_WARN_ALIGNMENT(vsx, regs);
return emulate_vsx(addr, reg, areg, regs, flags, nb);
}
#endif
@@ -794,7 +794,7 @@ int fix_alignment(struct pt_regs *regs)
* the exception of DCBZ which is handled as a special case here
*/
if (instr == DCBZ) {
- PPC_WARN_EMULATED(dcbz);
+ PPC_WARN_ALIGNMENT(dcbz, regs);
return emulate_dcbz(regs, addr);
}
if (unlikely(nb == 0))
@@ -804,7 +804,7 @@ int fix_alignment(struct pt_regs *regs)
* function
*/
if (flags & M) {
- PPC_WARN_EMULATED(multiple);
+ PPC_WARN_ALIGNMENT(multiple, regs);
return emulate_multiple(regs, addr, reg, nb,
flags, instr, swiz);
}
@@ -825,11 +825,11 @@ int fix_alignment(struct pt_regs *regs)
/* Special case for 16-byte FP loads and stores */
if (nb == 16) {
- PPC_WARN_EMULATED(fp_pair);
+ PPC_WARN_ALIGNMENT(fp_pair, regs);
return emulate_fp_pair(addr, reg, flags);
}
- PPC_WARN_EMULATED(unaligned);
+ PPC_WARN_ALIGNMENT(unaligned, regs);
/* If we are loading, get the data from user space, else
* get it from register values
Index: linux.trees.git/arch/powerpc/kernel/traps.c
===================================================================
--- linux.trees.git.orig/arch/powerpc/kernel/traps.c 2009-09-01 15:11:03.000000000 +1000
+++ linux.trees.git/arch/powerpc/kernel/traps.c 2009-09-14 09:47:23.000000000 +1000
@@ -759,7 +759,7 @@ static int emulate_instruction(struct pt
/* Emulate the mfspr rD, PVR. */
if ((instword & PPC_INST_MFSPR_PVR_MASK) == PPC_INST_MFSPR_PVR) {
- PPC_WARN_EMULATED(mfpvr);
+ PPC_WARN_EMULATED(mfpvr, regs);
rd = (instword >> 21) & 0x1f;
regs->gpr[rd] = mfspr(SPRN_PVR);
return 0;
@@ -767,7 +767,7 @@ static int emulate_instruction(struct pt
/* Emulating the dcba insn is just a no-op. */
if ((instword & PPC_INST_DCBA_MASK) == PPC_INST_DCBA) {
- PPC_WARN_EMULATED(dcba);
+ PPC_WARN_EMULATED(dcba, regs);
return 0;
}
@@ -776,7 +776,7 @@ static int emulate_instruction(struct pt
int shift = (instword >> 21) & 0x1c;
unsigned long msk = 0xf0000000UL >> shift;
- PPC_WARN_EMULATED(mcrxr);
+ PPC_WARN_EMULATED(mcrxr, regs);
regs->ccr = (regs->ccr & ~msk) | ((regs->xer >> shift) & msk);
regs->xer &= ~0xf0000000UL;
return 0;
@@ -784,19 +784,19 @@ static int emulate_instruction(struct pt
/* Emulate load/store string insn. */
if ((instword & PPC_INST_STRING_GEN_MASK) == PPC_INST_STRING) {
- PPC_WARN_EMULATED(string);
+ PPC_WARN_EMULATED(string, regs);
return emulate_string_inst(regs, instword);
}
/* Emulate the popcntb (Population Count Bytes) instruction. */
if ((instword & PPC_INST_POPCNTB_MASK) == PPC_INST_POPCNTB) {
- PPC_WARN_EMULATED(popcntb);
+ PPC_WARN_EMULATED(popcntb, regs);
return emulate_popcntb_inst(regs, instword);
}
/* Emulate isel (Integer Select) instruction */
if ((instword & PPC_INST_ISEL_MASK) == PPC_INST_ISEL) {
- PPC_WARN_EMULATED(isel);
+ PPC_WARN_EMULATED(isel, regs);
return emulate_isel(regs, instword);
}
@@ -995,7 +995,7 @@ void SoftwareEmulation(struct pt_regs *r
#ifdef CONFIG_MATH_EMULATION
errcode = do_mathemu(regs);
if (errcode >= 0)
- PPC_WARN_EMULATED(math);
+ PPC_WARN_EMULATED(math, regs);
switch (errcode) {
case 0:
@@ -1018,7 +1018,7 @@ void SoftwareEmulation(struct pt_regs *r
#elif defined(CONFIG_8XX_MINIMAL_FPEMU)
errcode = Soft_emulate_8xx(regs);
if (errcode >= 0)
- PPC_WARN_EMULATED(8xx);
+ PPC_WARN_EMULATED(8xx, regs);
switch (errcode) {
case 0:
@@ -1129,7 +1129,7 @@ void altivec_assist_exception(struct pt_
flush_altivec_to_thread(current);
- PPC_WARN_EMULATED(altivec);
+ PPC_WARN_EMULATED(altivec, regs);
err = emulate_altivec(regs);
if (err == 0) {
regs->nip += 4; /* skip emulated instruction */
^ permalink raw reply
* [PATCH 1/3] perf_event: Add alignment-faults and emulation-faults software events
From: Anton Blanchard @ 2009-10-18 11:09 UTC (permalink / raw)
To: benh, mingo, paulus, a.p.zijlstra; +Cc: linuxppc-dev, linux-kernel
Add two more sw events that are common to many cpus.
Alignment faults: When a load or store is not aligned properly.
Emulation faults: When an instruction is emulated in software.
Both cause a very significant slowdown (100x or worse), so identifying and
fixing them is very important.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux.trees.git/include/linux/perf_event.h
===================================================================
--- linux.trees.git.orig/include/linux/perf_event.h 2009-10-16 11:17:17.000000000 +1100
+++ linux.trees.git/include/linux/perf_event.h 2009-10-16 11:17:29.000000000 +1100
@@ -102,6 +102,8 @@ enum perf_sw_ids {
PERF_COUNT_SW_CPU_MIGRATIONS = 4,
PERF_COUNT_SW_PAGE_FAULTS_MIN = 5,
PERF_COUNT_SW_PAGE_FAULTS_MAJ = 6,
+ PERF_COUNT_SW_ALIGNMENT_FAULTS = 7,
+ PERF_COUNT_SW_EMULATION_FAULTS = 8,
PERF_COUNT_SW_MAX, /* non-ABI */
};
Index: linux.trees.git/include/linux/perf_counter.h
===================================================================
--- linux.trees.git.orig/include/linux/perf_counter.h 2009-10-16 11:16:10.000000000 +1100
+++ linux.trees.git/include/linux/perf_counter.h 2009-10-16 11:17:29.000000000 +1100
@@ -106,6 +106,8 @@ enum perf_sw_ids {
PERF_COUNT_SW_CPU_MIGRATIONS = 4,
PERF_COUNT_SW_PAGE_FAULTS_MIN = 5,
PERF_COUNT_SW_PAGE_FAULTS_MAJ = 6,
+ PERF_COUNT_SW_ALIGNMENT_FAULTS = 7,
+ PERF_COUNT_SW_EMULATION_FAULTS = 8,
PERF_COUNT_SW_MAX, /* non-ABI */
};
Index: linux.trees.git/kernel/perf_event.c
===================================================================
--- linux.trees.git.orig/kernel/perf_event.c 2009-10-16 11:17:17.000000000 +1100
+++ linux.trees.git/kernel/perf_event.c 2009-10-16 11:17:29.000000000 +1100
@@ -4255,6 +4255,8 @@ static const struct pmu *sw_perf_event_i
case PERF_COUNT_SW_PAGE_FAULTS_MAJ:
case PERF_COUNT_SW_CONTEXT_SWITCHES:
case PERF_COUNT_SW_CPU_MIGRATIONS:
+ case PERF_COUNT_SW_ALIGNMENT_FAULTS:
+ case PERF_COUNT_SW_EMULATION_FAULTS:
if (!event->parent) {
atomic_inc(&perf_swevent_enabled[event_id]);
event->destroy = sw_perf_event_destroy;
Index: linux.trees.git/tools/perf/design.txt
===================================================================
--- linux.trees.git.orig/tools/perf/design.txt 2009-10-16 11:16:10.000000000 +1100
+++ linux.trees.git/tools/perf/design.txt 2009-10-16 11:17:29.000000000 +1100
@@ -137,6 +137,8 @@ enum sw_event_ids {
PERF_COUNT_SW_CPU_MIGRATIONS = 4,
PERF_COUNT_SW_PAGE_FAULTS_MIN = 5,
PERF_COUNT_SW_PAGE_FAULTS_MAJ = 6,
+ PERF_COUNT_SW_ALIGNMENT_FAULTS = 7,
+ PERF_COUNT_SW_EMULATION_FAULTS = 8,
};
Counters of the type PERF_TYPE_TRACEPOINT are available when the ftrace event
Index: linux.trees.git/tools/perf/util/parse-events.c
===================================================================
--- linux.trees.git.orig/tools/perf/util/parse-events.c 2009-10-16 11:16:10.000000000 +1100
+++ linux.trees.git/tools/perf/util/parse-events.c 2009-10-16 11:17:29.000000000 +1100
@@ -47,6 +47,8 @@ static struct event_symbol event_symbols
{ CSW(PAGE_FAULTS_MAJ), "major-faults", "" },
{ CSW(CONTEXT_SWITCHES), "context-switches", "cs" },
{ CSW(CPU_MIGRATIONS), "cpu-migrations", "migrations" },
+ { CSW(ALIGNMENT_FAULTS), "alignment-faults", "" },
+ { CSW(EMULATION_FAULTS), "emulation-faults", "" },
};
#define __PERF_EVENT_FIELD(config, name) \
@@ -75,6 +77,8 @@ static const char *sw_event_names[] = {
"CPU-migrations",
"minor-faults",
"major-faults",
+ "alignment-faults",
+ "emulation-faults",
};
#define MAX_ALIASES 8
^ permalink raw reply
* Re: [PATCH] powerpc: tracing: Add powerpc tracepoints for interrupt entry and exit
From: Anton Blanchard @ 2009-10-18 11:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Frederic Weisbecker, Ingo Molnar, linuxppc-dev, Steven Rostedt
In-Reply-To: <1255501071.2347.42.camel@pasglop>
Hi Ben,
> Breaks 6xx_defconfig:
Yuck. Since the CREATE_TRACE_POINTS stuff appears to need a non trivial number
of includes it might be best just to fold it into one of the tracepoint call
sites like this.
--
This patch adds powerpc specific tracepoints for interrupt entry and exit.
While we already have generic irq_handler_entry and irq_handler_exit
tracepoints there are cases on our virtualised powerpc machines where an
interrupt is presented to the OS, but subsequently handled by the hypervisor.
This means no OS interrupt handler is invoked.
Here is an example on a POWER6 machine with the patch below applied:
<idle>-0 [006] 3243.949840744: irq_entry: pt_regs=c0000000ce31fb10
<idle>-0 [006] 3243.949850520: irq_exit: pt_regs=c0000000ce31fb10
<idle>-0 [007] 3243.950218208: irq_entry: pt_regs=c0000000ce323b10
<idle>-0 [007] 3243.950224080: irq_exit: pt_regs=c0000000ce323b10
<idle>-0 [000] 3244.021879320: irq_entry: pt_regs=c000000000a63aa0
<idle>-0 [000] 3244.021883616: irq_handler_entry: irq=87 handler=eth0
<idle>-0 [000] 3244.021887328: irq_handler_exit: irq=87 return=handled
<idle>-0 [000] 3244.021897408: irq_exit: pt_regs=c000000000a63aa0
Here we see two phantom interrupts (no handler was invoked), followed
by a real interrupt for eth0. Without the tracepoints in this patch we
would have missed the phantom interrupts.
Since these would be the first arch specific tracepoints, I'd like to make
sure we agree on naming. The tracepoints live in events/powerpc/*, but I'm
wondering if the tracepoint name should also contain the arch name, eg
powerpc_irq_entry/powerpc_irq_exit. Thoughts?
Signed-off-by: Anton Blanchard <anton@samba.org>
--
Index: linux.trees.git/arch/powerpc/include/asm/trace.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux.trees.git/arch/powerpc/include/asm/trace.h 2009-10-17 08:45:08.000000000 +1100
@@ -0,0 +1,53 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM powerpc
+
+#if !defined(_TRACE_POWERPC_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_POWERPC_H
+
+#include <linux/tracepoint.h>
+
+struct pt_regs;
+
+TRACE_EVENT(irq_entry,
+
+ TP_PROTO(struct pt_regs *regs),
+
+ TP_ARGS(regs),
+
+ TP_STRUCT__entry(
+ __field(struct pt_regs *, regs)
+ ),
+
+ TP_fast_assign(
+ __entry->regs = regs;
+ ),
+
+ TP_printk("pt_regs=%p", __entry->regs)
+);
+
+TRACE_EVENT(irq_exit,
+
+ TP_PROTO(struct pt_regs *regs),
+
+ TP_ARGS(regs),
+
+ TP_STRUCT__entry(
+ __field(struct pt_regs *, regs)
+ ),
+
+ TP_fast_assign(
+ __entry->regs = regs;
+ ),
+
+ TP_printk("pt_regs=%p", __entry->regs)
+);
+
+#endif /* _TRACE_POWERPC_H */
+
+#undef TRACE_INCLUDE_PATH
+#undef TRACE_INCLUDE_FILE
+
+#define TRACE_INCLUDE_PATH asm
+#define TRACE_INCLUDE_FILE trace
+
+#include <trace/define_trace.h>
Index: linux.trees.git/arch/powerpc/kernel/irq.c
===================================================================
--- linux.trees.git.orig/arch/powerpc/kernel/irq.c 2009-10-17 08:44:32.000000000 +1100
+++ linux.trees.git/arch/powerpc/kernel/irq.c 2009-10-17 08:45:44.000000000 +1100
@@ -70,6 +70,8 @@
#include <asm/firmware.h>
#include <asm/lv1call.h>
#endif
+#define CREATE_TRACE_POINTS
+#include <asm/trace.h>
int __irq_offset_value;
static int ppc_spurious_interrupts;
@@ -325,6 +327,8 @@ void do_IRQ(struct pt_regs *regs)
struct pt_regs *old_regs = set_irq_regs(regs);
unsigned int irq;
+ trace_irq_entry(regs);
+
irq_enter();
check_stack_overflow();
@@ -348,6 +352,8 @@ void do_IRQ(struct pt_regs *regs)
timer_interrupt(regs);
}
#endif
+
+ trace_irq_exit(regs);
}
void __init init_IRQ(void)
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Felix Radensky @ 2009-10-18 9:38 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org,
Adrian Hunter
In-Reply-To: <20091016153128.GA11838@loki.buserror.net>
Hi, Scott
Scott Wood wrote:
> On Fri, Oct 16, 2009 at 07:01:43AM +0200, Felix Radensky wrote:
>> Thanks for confirmation. So the real problem is eLBC ?
>> What happens if I access other devices on eLBC (e.g. FPGA)
>> simultaneously with NAND or NOR ?
>
> AFAICT, the problem is NAND being accessed simultaneously with anything else
> on the eLBC (at least GPCM -- not sure about UPM). Instead of delaying the
> memory-like transaction until the NAND special operation has completed, it
> seems to just abort the NAND operation.
>
> eLBC can't really tell the difference whether you've got NOR or FPGA hooked
> up to a GPCM chip select, so the problem should still apply.
>
Can you please provide some code example of synchronizing GPCM and NAND ?
I may try implementing the NOR mapping driver you were talking about.
Thanks.
Felix.
^ permalink raw reply
* Re: [PATCH] hvc_console: returning 0 from put_chars is not an error
From: Timur Tabi @ 2009-10-17 23:17 UTC (permalink / raw)
To: Hendrik Brueckner, Scott Wood, Christian Borntraeger,
linuxppc-dev, Timur Tabi, Alan Cox, Linux Kernel Mailing List
In-Reply-To: <20091016084924.GB4234@linux.vnet.ibm.com>
On Fri, Oct 16, 2009 at 3:49 AM, Hendrik Brueckner
<brueckner@linux.vnet.ibm.com> wrote:
> The states are handled by the hvc_iucv itself:
> If the hvc_iucv code has a connection established, terminal or console data
> are queued and sent to the peer. If the state is disconnected, terminal and
> console data is discarded internally.
So what is the plan now?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Mixing hard and soft floating point?
From: Wolfgang Denk @ 2009-10-17 19:34 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev
In-Reply-To: <OFEC00B9FB.B03AA854-ONC1257652.00644350-C1257652.00651551@transmode.se>
Dear Joakim Tjernlund,
In message <OFEC00B9FB.B03AA854-ONC1257652.00644350-C1257652.00651551@transmode.se> you wrote:
>
> > Recompile and relink it with soft-fp as well. Or ask the provider to
> > do that.
>
> That is what I am trying do/find out. The supplier claims that
> it should not be a problem and is ATM unwilling to recompile the app/libs.
> I am not convinced won't cause problems, not to mention performance degradation.
If the application is really using FP instructions a lot, then there
is a huge difference between using soft-float and MATH_EMU; I
remember test cases where soft-float was faster by factors of
500...1000.
> OK, but then you don't mix some libs/apps with soft and other
> apps/libs with hard FP?
No, we never tried that. Sounds scary to me.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The connection between the language in which we think/program and the
problems and solutions we can imagine is very close. For this reason
restricting language features with the intent of eliminating pro-
grammer errors is at best dangerous.
- Bjarne Stroustrup in "The C++ Programming Language"
^ permalink raw reply
* Re: Mixing hard and soft floating point?
From: Joakim Tjernlund @ 2009-10-17 18:24 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20091017181224.97FFBF15432@gemini.denx.de>
Wolfgang Denk <wd@denx.de> wrote on 17/10/2009 20:12:24:
>
> Dear Joakim Tjernlund,
>
> In message <OFC920E57F.DFABC29F-ONC1257652.00421E11-C1257652.
> 0043478A@transmode.se> you wrote:
> >
> > Anyone tried mixing hard and soft FP in on soft float CPU such as 83xx?
>
> Hm... most 83xx have a FPU.
Yeah, I meant 832x. These don't have a FPU
>
> > Been trying to figure out if this is a good idea or not.
> > Any combinations that will or won't work?
>
> What exactly do you mean by "mixing"? You cannot (at least not with
> any reasonable effort) mix hard and soft FP in the same application /
> linked object. And it would be pretty difficult to setup separate
> libraries for and all that stuff for both hard and soft FP binaries
> in one system.
I meant on per app or per lib basis, not within the same
app/lib.
>
> I doubt if such a setup makes sense at all.
>
> > Generally I got soft FP in all system libs but there might be
> > an binary application which will use hard FP.
>
> Recompile and relink it with soft-fp as well. Or ask the provider to
> do that.
That is what I am trying do/find out. The supplier claims that
it should not be a problem and is ATM unwilling to recompile the app/libs.
I am not convinced won't cause problems, not to mention performance degradation.
>
> > Is the MATH_EMU option in the kernel reliable(for 8xx too)?
>
> It's reliable enough to install and run standard distributions like
> Debian, Ubuntu, or Fedora, but I have to admit that we haven't stress
> tested any special FP test suites in such an environment. In everyday
> use I didn't see any real issues, though.
OK, but then you don't mix some libs/apps with soft and other
apps/libs with hard FP?
Jocke
^ 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