| Message ID | 1320883635-17194-9-git-send-email-Kyle.D.Moffett@boeing.com (mailing list archive) |
|---|---|
| State | RFC |
| Headers | show |
On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote: > As FreeScale e500 systems have different cacheline sizes from e500mc, it > is basically impossible for the kernel to support both in a single > system image at present. > > Given that one is SPE-float and the other is classic-float, they are not > generally userspace-compatible either. > > This patch updates the conditional to depend on whether the system is > actually targetting an "e500" or "e500mc" core and entirely removes the > unused sync-to-lwsync-replacement on e500v1/e500v2 systems. > > Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com> > --- > arch/powerpc/include/asm/synch.h | 16 ++++------------ > 1 files changed, 4 insertions(+), 12 deletions(-) Nak, we can run an e500mc in a mode that is compatible with e500v1/v2. I see no reason to change the support we have there. - k
On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote: > > On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote: > > > As FreeScale e500 systems have different cacheline sizes from e500mc, it > > is basically impossible for the kernel to support both in a single > > system image at present. > > > > Given that one is SPE-float and the other is classic-float, they are not > > generally userspace-compatible either. > > > > This patch updates the conditional to depend on whether the system is > > actually targetting an "e500" or "e500mc" core and entirely removes the > > unused sync-to-lwsync-replacement on e500v1/e500v2 systems. > > > > Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com> > > --- > > arch/powerpc/include/asm/synch.h | 16 ++++------------ > > 1 files changed, 4 insertions(+), 12 deletions(-) > > Nak, we can run an e500mc in a mode that is compatible with e500v1/v2. I see no reason to change the support we have there. What "mode" do you mean? DCBZ32? We don't support using that currently, and I'd imagine the performance implication would be such that you'd never want to do it unless it's the only way to make some piece of legacy software work. > I see no reason to change the support we have there. No reason to remove complexity that is not needed, and is not planned to be needed? -Scott
On Nov 10, 2011, at 10:31 AM, Scott Wood wrote: > On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote: >> >> On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote: >> >>> As FreeScale e500 systems have different cacheline sizes from e500mc, it >>> is basically impossible for the kernel to support both in a single >>> system image at present. >>> >>> Given that one is SPE-float and the other is classic-float, they are not >>> generally userspace-compatible either. >>> >>> This patch updates the conditional to depend on whether the system is >>> actually targetting an "e500" or "e500mc" core and entirely removes the >>> unused sync-to-lwsync-replacement on e500v1/e500v2 systems. >>> >>> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com> >>> --- >>> arch/powerpc/include/asm/synch.h | 16 ++++------------ >>> 1 files changed, 4 insertions(+), 12 deletions(-) >> >> Nak, we can run an e500mc in a mode that is compatible with e500v1/v2. I see no reason to change the support we have there. > > What "mode" do you mean? DCBZ32? We don't support using that currently, > and I'd imagine the performance implication would be such that you'd > never want to do it unless it's the only way to make some piece of legacy > software work. Correct, DCBZ32, we've had customers that go down this path. >> I see no reason to change the support we have there. > > No reason to remove complexity that is not needed, and is not planned to > be needed? I'd rather wait for at least 2 years for e500mc devices to have further deployment before we'd remove this. - k
On Thu, Nov 10, 2011 at 10:42:25AM -0600, Kumar Gala wrote: > > On Nov 10, 2011, at 10:31 AM, Scott Wood wrote: > > > On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote: > >> Nak, we can run an e500mc in a mode that is compatible with e500v1/v2. I see no reason to change the support we have there. > > > > What "mode" do you mean? DCBZ32? We don't support using that currently, > > and I'd imagine the performance implication would be such that you'd > > never want to do it unless it's the only way to make some piece of legacy > > software work. > > Correct, DCBZ32, we've had customers that go down this path. For running legacy software, or for multiplatform Linux kernels? And if you're willing to toss performance away for this goal, why do you need lwsync? :-) DCBZ32 is not a "mode that is compatible with v1/v2", BTW. It only affects cache block size (for dcbz/dcba only), not SPE versus FP, not changes in power management, not changes in machine check handling, etc. Using DCBZ32 for the kernel would also complicate switching the kernel to dcbzl, to support enabling DCBZ32 for certain userspace apps (a more likely use case) without making it systemwide. -Scott
On Nov 10, 2011, at 12:03, Scott Wood wrote: > On Thu, Nov 10, 2011 at 10:42:25AM -0600, Kumar Gala wrote: >> >> On Nov 10, 2011, at 10:31 AM, Scott Wood wrote: >> >>> On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote: >>>> Nak, we can run an e500mc in a mode that is compatible with e500v1/v2. >>>> I see no reason to change the support we have there. >>> >>> What "mode" do you mean? DCBZ32? We don't support using that currently, >>> and I'd imagine the performance implication would be such that you'd >>> never want to do it unless it's the only way to make some piece of legacy >>> software work. >> >> Correct, DCBZ32, we've had customers that go down this path. > > For running legacy software, or for multiplatform Linux kernels? > > And if you're willing to toss performance away for this goal, why do you > need lwsync? :-) > > DCBZ32 is not a "mode that is compatible with v1/v2", BTW. It only > affects cache block size (for dcbz/dcba only), not SPE versus FP, not > changes in power management, not changes in machine check handling, etc. > > Using DCBZ32 for the kernel would also complicate switching the kernel to > dcbzl, to support enabling DCBZ32 for certain userspace apps (a more > likely use case) without making it systemwide. So, as far as I can tell the kernel doesn't even try to touch DCBZ32. Even if it did, if you are building a new kernel that includes this patch, surely you can actually build a proper e500mc kernel instead of trying to build a new kernel to run on hardware it wasn't designed to run on, right? I think the bigger issue is the fact that building a PPC_BOOK3E_64 kernel with both e5500 and PowerPC A2 support turned on will not actually run on both. Before my v1-patch-series, machine-check handling is messed up for PowerPC A2, and afterwards cacheline sizes are messed up for e5500. Does this mean that PPC_BOOK3E_64 needs to be split into two separate Book 3-III families the same way that 32-bit has been split? Is there another way around it? Cheers, Kyle Moffett
On Nov 10, 2011, at 2:27 PM, Moffett, Kyle D wrote: > On Nov 10, 2011, at 12:03, Scott Wood wrote: >> On Thu, Nov 10, 2011 at 10:42:25AM -0600, Kumar Gala wrote: >>> >>> On Nov 10, 2011, at 10:31 AM, Scott Wood wrote: >>> >>>> On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote: >>>>> Nak, we can run an e500mc in a mode that is compatible with e500v1/v2. >>>>> I see no reason to change the support we have there. >>>> >>>> What "mode" do you mean? DCBZ32? We don't support using that currently, >>>> and I'd imagine the performance implication would be such that you'd >>>> never want to do it unless it's the only way to make some piece of legacy >>>> software work. >>> >>> Correct, DCBZ32, we've had customers that go down this path. >> >> For running legacy software, or for multiplatform Linux kernels? >> >> And if you're willing to toss performance away for this goal, why do you >> need lwsync? :-) >> >> DCBZ32 is not a "mode that is compatible with v1/v2", BTW. It only >> affects cache block size (for dcbz/dcba only), not SPE versus FP, not >> changes in power management, not changes in machine check handling, etc. >> >> Using DCBZ32 for the kernel would also complicate switching the kernel to >> dcbzl, to support enabling DCBZ32 for certain userspace apps (a more >> likely use case) without making it systemwide. > > So, as far as I can tell the kernel doesn't even try to touch DCBZ32. Correct, it was my thinking I'd get there an add this one day, that day never came. > Even if it did, if you are building a new kernel that includes this patch, > surely you can actually build a proper e500mc kernel instead of trying to > build a new kernel to run on hardware it wasn't designed to run on, right? > > I think the bigger issue is the fact that building a PPC_BOOK3E_64 kernel > with both e5500 and PowerPC A2 support turned on will not actually run on > both. Before my v1-patch-series, machine-check handling is messed up for > PowerPC A2, and afterwards cacheline sizes are messed up for e5500. That might be, but who is asking or wanting to run a BOOK3E_64 kernel on both. I'm guessing there are a number of issues with this. > Does this mean that PPC_BOOK3E_64 needs to be split into two separate > Book 3-III families the same way that 32-bit has been split? Is there > another way around it? No idea, we have to ask Ben how much he cares. I don't see any FSL customers pushing us to run the same kernel on A2 and P5020 (or future FSL devices). - k
On Thu, 2011-11-10 at 14:27 -0600, Moffett, Kyle D wrote: > > Does this mean that PPC_BOOK3E_64 needs to be split into two separate > Book 3-III families the same way that 32-bit has been split? Is there > another way around it? No, I don't want more split, on the contrary. Cheers, Ben.
On Thu, 2011-11-10 at 14:34 -0600, Kumar Gala wrote: > No idea, we have to ask Ben how much he cares. I don't see any FSL > customers pushing us to run the same kernel on A2 and P5020 (or future > FSL devices). I do care. For example, imagine somebody wanting to support an enterprise distro on both BG/Q and some FSL based HW ... Besides, this has generally forced us to do things more cleanly and I don't want to go back into #ifdef land. These cores are both arch 2.06 E compilant, there is no good reason to prevent or forbid having them build into a single binary image. Look at the mess ARM got into and the pain they are having getting out of with that stuff ... No way I'm going backward with split configs. If anything, I'd like to reconcile things even more. Cheers, Ben.
diff --git a/arch/powerpc/include/asm/synch.h b/arch/powerpc/include/asm/synch.h index d7cab44..3d518b6 100644 --- a/arch/powerpc/include/asm/synch.h +++ b/arch/powerpc/include/asm/synch.h @@ -5,8 +5,11 @@ #include <linux/stringify.h> #include <asm/feature-fixups.h> -#if defined(__powerpc64__) || defined(CONFIG_PPC_E500MC) +#if defined(__powerpc64__) || defined(CONFIG_FSL_E500MC) #define __SUBARCH_HAS_LWSYNC +#define LWSYNC lwsync +#else +#define LWSYNC sync #endif #ifndef __ASSEMBLY__ @@ -25,17 +28,6 @@ static inline void isync(void) } #endif /* __ASSEMBLY__ */ -#if defined(__powerpc64__) -# define LWSYNC lwsync -#elif defined(CONFIG_E500) -# define LWSYNC \ - START_LWSYNC_SECTION(96); \ - sync; \ - MAKE_LWSYNC_SECTION_ENTRY(96, __lwsync_fixup); -#else -# define LWSYNC sync -#endif - #ifdef CONFIG_SMP #define __PPC_ACQUIRE_BARRIER \ START_LWSYNC_SECTION(97); \
As FreeScale e500 systems have different cacheline sizes from e500mc, it is basically impossible for the kernel to support both in a single system image at present. Given that one is SPE-float and the other is classic-float, they are not generally userspace-compatible either. This patch updates the conditional to depend on whether the system is actually targetting an "e500" or "e500mc" core and entirely removes the unused sync-to-lwsync-replacement on e500v1/e500v2 systems. Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com> --- arch/powerpc/include/asm/synch.h | 16 ++++------------ 1 files changed, 4 insertions(+), 12 deletions(-)