Message ID | 1275270628.1931.540.camel@pasglop (mailing list archive) |
---|---|
State | Accepted, archived |
Headers | show |
On Mon, 2010-05-31 at 11:50 +1000, Benjamin Herrenschmidt wrote: > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> > --- > arch/powerpc/kernel/ppc_ksyms.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Alex, this is just a temporary fix to remove the build breakage for 40x etc... but please, update KVM to just build-in its own. Don't we have .o's that are always built into modules nowadays ? Cheers, Ben.
On 31.05.2010, at 04:00, Benjamin Herrenschmidt wrote: > On Mon, 2010-05-31 at 11:50 +1000, Benjamin Herrenschmidt wrote: >> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> >> --- >> arch/powerpc/kernel/ppc_ksyms.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) > > Alex, this is just a temporary fix to remove the build breakage for 40x > etc... but please, update KVM to just build-in its own. What's the bad part in reusing the existing code? > Don't we have .o's that are always built into modules nowadays ? I don't think I understand what you mean. Alex
Alexander Graf <agraf@suse.de> writes: > On 31.05.2010, at 04:00, Benjamin Herrenschmidt wrote: > >> On Mon, 2010-05-31 at 11:50 +1000, Benjamin Herrenschmidt wrote: >>> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> >>> --- >>> arch/powerpc/kernel/ppc_ksyms.c | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> Alex, this is just a temporary fix to remove the build breakage for 40x >> etc... but please, update KVM to just build-in its own. > > What's the bad part in reusing the existing code? The bad part is that KVM is wasting a ridiculous amount of stack space by allocating multiple instances of struct task_struct on it. I have a patch removing all of it, but I haven't tested it yet. Andreas.
On Mon, 2010-05-31 at 11:33 +0200, Alexander Graf wrote: > > Alex, this is just a temporary fix to remove the build breakage for > 40x > > etc... but please, update KVM to just build-in its own. > > What's the bad part in reusing the existing code? I'm not saying we should dup the code, but I'm sure we can find a better way for that sort of stuff, along with other base support bits like you normally find in libgcc, to be linked directly with all modules. calling out of modules symbols sucks for perf too anyways. > > Don't we have .o's that are always built into modules nowadays ? > > I don't think I understand what you mean. Ben.
Andreas Schwab wrote: > Alexander Graf <agraf@suse.de> writes: > > >> On 31.05.2010, at 04:00, Benjamin Herrenschmidt wrote: >> >> >>> On Mon, 2010-05-31 at 11:50 +1000, Benjamin Herrenschmidt wrote: >>> >>>> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> >>>> --- >>>> arch/powerpc/kernel/ppc_ksyms.c | 2 +- >>>> 1 files changed, 1 insertions(+), 1 deletions(-) >>>> >>> Alex, this is just a temporary fix to remove the build breakage for 40x >>> etc... but please, update KVM to just build-in its own. >>> >> What's the bad part in reusing the existing code? >> > > The bad part is that KVM is wasting a ridiculous amount of stack space > by allocating multiple instances of struct task_struct on it. I have a > patch removing all of it, but I haven't tested it yet. > Mind to send it over so I can take a look at it :)? Getting rid of the task_struct structs lying in the stack is certainly a good idea. Alex
diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c index bc9f39d..3b4dcc8 100644 --- a/arch/powerpc/kernel/ppc_ksyms.c +++ b/arch/powerpc/kernel/ppc_ksyms.c @@ -101,7 +101,7 @@ EXPORT_SYMBOL(pci_dram_offset); EXPORT_SYMBOL(start_thread); EXPORT_SYMBOL(kernel_thread); -#ifndef CONFIG_BOOKE +#ifdef CONFIG_PPC_FPU EXPORT_SYMBOL_GPL(cvt_df); EXPORT_SYMBOL_GPL(cvt_fd); #endif
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> --- arch/powerpc/kernel/ppc_ksyms.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)