headers
Michael Ellerman | 1 Oct 2009 05:36
Picon
Gravatar

Re: 64bit kernel is huge

On Mon, 2009-09-28 at 17:45 +1000, Anton Blanchard wrote:
> Hi,
> 
> I've found at least one machine that wont boot 2.6.31-rc* with a 
> pseries_defconfig. If I move real-base from 0xc00000 to 0xd00000 it
> boots fine.
> 
> # size vmlinux
>    text	   data	    bss	    dec	    hex	filename
> 9812942	1982496	1105228	12900666	 c4d93a	vmlinux
> 
> Looks like we blow right through the 12MB mark. It desperately needs to eat
> less and lose weight.
> 
> Here are some of the problem areas:
> 
> 131072  lppaca
> 65536   paca
> 
> I think we've attacked these before, not sure if there is anything left
> we can trim.

Why can't we dynamically allocate all but one paca? I seem to recall
Mikey tried it but it didn't work?

And on !ISERIES we should be able to allocate the lppacas too I think,
the HV doesn't know about them until register_vpa().

cheers
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Neuling | 1 Oct 2009 07:06
Gravatar

Re: 64bit kernel is huge


> 2.6.28     8647080	1699460	 780472	11127012	a9c8e4
> 2.6.27     7461663	1505796	 774400	9741859		94a623

If you compile 28 with the 27 pseries_config, you lose most of this
1.2MB text bloat.

If we remove just FUNCTION_TRACER and STACK_TRACER from 28 we gain back
about 600K.

Mikey
Permalink | Reply | 2 comments |
headers
Michael Neuling | 1 Oct 2009 07:09
Gravatar

Re: 64bit kernel is huge

> > 2.6.28     8647080	1699460	 780472	11127012	a9c8e4
> > 2.6.27     7461663	1505796	 774400	9741859		94a623
> 
> If you compile 28 with the 27 pseries_config, you lose most of this
> 1.2MB text bloat.
> 
> If we remove just FUNCTION_TRACER and STACK_TRACER from 28 we gain back
> about 600K.

EXT4 also adds about 200K, between the 27 and 28 configs.

Mikey
Permalink | Reply | 0 comments |
headers
Joakim Tjernlund | 1 Oct 2009 09:05
Picon

Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite

Benjamin Herrenschmidt <benh <at> kernel.crashing.org> wrote on 01/10/2009 00:35:59:
>
>
> > > Had a look at linus tree and there is something I don't understand.
> > > Your fix, e0908085fc2391c85b85fb814ae1df377c8e0dcb, fixes a problem
> > > that was introduced by 8d30c14cab30d405a05f2aaceda1e9ad57800f36 but
> > > 8d30c14cab30d405a05f2aaceda1e9ad57800f36 was included in .31 and .31
> > > works and top of tree does not, how can that be?
> > >
> > > To me it seems more likely that some mm change introduced between .31 and
> > > top of tree is the culprit.
> > > My patch addresses the problem described in the comment:
> > > /* On 8xx, cache control instructions (particularly
> > >  * "dcbst" from flush_dcache_icache) fault as write
> > >  * operation if there is an unpopulated TLB entry
> > >  * for the address in question. To workaround that,
> > >  * we invalidate the TLB here, thus avoiding dcbst
> > >  * misbehaviour.
> > >  */
> > > Now you are using this old fix to paper over some other bug or so I think.
> >
> > There is something fishy with the TLB status, looking into the mpc862 manual I
> > don't see how it can work reliably. Need to dwell some more.
> > Anyhow, I have incorporated some of my findings into a new patch,
> > perhaps this will be the golden one?
>
> Well, I still wonder about what whole unpopulated entry business.

Yes, is a odd compared to the other ppc arch. I know why it is there
and I also know that there is alternative way to work around the problem
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ingo Molnar | 1 Oct 2009 09:42
Picon
Picon
Favicon

Re: [PATCH] perf_event, powerpc: Fix compilation after big perf_counter rename


* Stephen Rothwell <sfr <at> canb.auug.org.au> wrote:

> Hi Ingo,
> 
> On Thu, 24 Sep 2009 23:25:55 +1000 Michael Ellerman <michael <at> ellerman.id.au> wrote:
> >
> > Give me a day or two, I should be able to add a per-branch setting for
> > who to send mails to without too much trouble.
> 
> In the mean time I don't now if someone has pointed you at these today:
> 
> http://kisskb.ellerman.id.au/kisskb/branch/12/

That's an upstream warning.

-tip supports fail-on-build-warnings build mode (for the whole kernel) 
via the CONFIG_ALLOW_WARNINGS .config setting. So if you do allnoconfig 
builds, make sure you turn on CONFIG_ALLOW_WARNINGS=y to get the same 
build behavior as with Linus's tree.

	Ingo
Permalink | Reply | 2 comments |
headers
Stephen Rothwell | 1 Oct 2009 13:13
Picon
Picon

Re: [PATCH] perf_event, powerpc: Fix compilation after big perf_counter rename

Hi Ingo,

On Thu, 1 Oct 2009 09:42:01 +0200 Ingo Molnar <mingo <at> elte.hu> wrote:
>
> * Stephen Rothwell <sfr <at> canb.auug.org.au> wrote:
> 
> > On Thu, 24 Sep 2009 23:25:55 +1000 Michael Ellerman <michael <at> ellerman.id.au> wrote:
> > >
> > > Give me a day or two, I should be able to add a per-branch setting for
> > > who to send mails to without too much trouble.
> > 
> > In the mean time I don't now if someone has pointed you at these today:
> > 
> > http://kisskb.ellerman.id.au/kisskb/branch/12/
> 
> That's an upstream warning.

When I sent that to you, I was referring to these build results:

http://kisskb.ellerman.id.au/kisskb/buildresult/1307802/

which (as you say) was only a waning in the rest of the kernel but is
turned into an error by the -Werror we use when building arch/powerpc.
The warning came from commit 4765c1db84c73f775eb1822a009117cbae524e9e
("rcu-tiny: The Bloatwatch Edition, v6") in the -tip tree and fixed by
commit 5ef9b8e59c043624fb44e31439cecf7f8b4cd62a ("rcu: Clean up the
warning message about RCU not defined") the next day (in the -tip tree).
So no big problem.  Neither of these commits are upstream.

I was just filling in the role of notifying you of build problems until
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anton Vorontsov | 1 Oct 2009 20:38

[PATCH] powerpc/kgdb: Fix build failure caused by "kgdb.c: unused variable 'acc'"

'acc' isn't used anywhere and thus triggers gcc warning, which causes
build error with CONFIG_PPC_DISABLE_WERROR=n (default):

  cc1: warnings being treated as errors
  arch/powerpc/kernel/kgdb.c: In function 'gdb_regs_to_pt_regs':
  arch/powerpc/kernel/kgdb.c:289: warning: unused variable 'acc'
  make[1]: *** [arch/powerpc/kernel/kgdb.o] Error 1

Signed-off-by: Anton Vorontsov <avorontsov <at> ru.mvista.com>
---
 arch/powerpc/kernel/kgdb.c |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
index fe8f71d..641c74b 100644
--- a/arch/powerpc/kernel/kgdb.c
+++ b/arch/powerpc/kernel/kgdb.c
 <at>  <at>  -282,12 +282,6  <at>  <at>  void gdb_regs_to_pt_regs(unsigned long *gdb_regs, struct pt_regs *regs)
 {
 	unsigned long *ptr = gdb_regs;
 	int reg;
-#ifdef CONFIG_SPE
-	union {
-		u32 v32[2];
-		u64 v64;
-	} acc;
-#endif

 	for (reg = 0; reg < 32; reg++)
 		UNPACK64(regs->gpr[reg], ptr);
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Bonesio | 1 Oct 2009 20:45
Picon

Re: [PATCH] powerpc/5200: add LocalPlus bus FIFO device driver

Hi Albrecht,

Thanks for the comments. My replies are below.

- John

On Wed, 2009-09-30 at 20:34 +0200, Albrecht Dreß wrote:
> Hi John:
> 
> Cool stuff - Grant's original one also helped me a lot to get Bestcomm  
> running for me (I use it only for read dma)!
> 
> Am 29.09.09 22:43 schrieb(en) John Bonesio:
> [snip]
> > +		 * It may be worth experimenting with the ALARM value  
> > to see if
> > +		 * there is a performance impacit.  However, if it is  
> > wrong there
> > +		 * is a risk of DMA not transferring the last chunk of  
> > data
> > +		 */
> > +		if (write) {
> > +			out_be32(lpbfifo.regs + LPBFIFO_REG_FIFO_ALARM,  
> > 0x1e4);
> > +			out_8(lpbfifo.regs + LPBFIFO_REG_FIFO_CONTROL,  
> > 7);
> > +			lpbfifo.bcom_cur_task = lpbfifo.bcom_tx_task;
> > +		} else {
> > +			out_be32(lpbfifo.regs + LPBFIFO_REG_FIFO_ALARM,  
> > 0x1ff);
(Continue reading)

Permalink | Reply | 2 comments |
headers
Albrecht Dreß | 1 Oct 2009 21:31
Picon
Favicon

Re: [PATCH] powerpc/5200: add LocalPlus bus FIFO device driver

Hi John:

Am 01.10.09 20:45 schrieb(en) John Bonesio:
> Nowhere in the text does it say 0 and 1 are the only possible values.  
> And since GR is a 3 bit field instead of a 1 bit field, that implied  
> that to me that other values are allowed.
> 
> I can see how one could read the text as saying 0 and 1 are the only  
> values allowed. However, empirical the testing I've done, seems to  
> indicate that the '7' is a valid value, as it produced different  
> behavior than 1.

Thanks for the clarification!

> I've put in the suggested change to set the 'flush' bit. It didn't  
> seem to help. I'm not sure what else might be different between my  
> system and yours.

My board is a self-designed one, roughly Icecube-based, with a 5200B.   
The peripheral (actually a second processor) is attached in 16-bit mode  
to the LPB.  The main data flow goes to the 5200, so I have only a task  
for reading data.  As the block transfer is only one part (but with a  
huge block size) in a transaction, I allocate only one block for the  
task, i.e. I call bcom_gen_bd_rx_init(1, ...).

The transaction size is always a multiple of 4 bytes, and I use the  
same value for the FIFO packet size and struct bcom_bd::status.  In the  
Control reg, I set CS, BPT=4, DAI, RWb and Flush.  I can isolate the  
code launching Bestcomm if you're interested.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Albrecht Dreß | 1 Oct 2009 21:55
Picon
Favicon

[PATCH] powerpc/5200: make BestComm gen_bd microcode exchangeable

This patch adds a method for defining different microcodes than the  
pe-defined ones for the MPC52xx processor's BestComm General Buffer  
Descriptor (gen_db) tasks.  The default microcode is still the one from  
bcom_gen_bd_[rt]x_task, but it can be replaced by calling  
bcom_gen_bd_set_microcode() which is more efficient than explicitly  
loading it via bcom_load_image() after each bcom_gen_bd_[rt]x_reset().

Signed-off-by: Albrecht Dreß <albrecht.dress <at> arcor.de>

---

diff -uprN -X linux-2.6.30.3/Documentation/dontdiff  
linux-2.6.30.3.orig/arch/powerpc/sysdev/bestcomm/gen_bd.c  
linux-2.6.30.3/arch/powerpc/sysdev/bestcomm/gen_bd.c
--- linux-2.6.30.3.orig/arch/powerpc/sysdev/bestcomm/gen_bd.c	 
2009-07-24 23:47:51.000000000 +0200
+++ linux-2.6.30.3/arch/powerpc/sysdev/bestcomm/gen_bd.c	 
2009-10-01 14:26:33.000000000 +0200
 <at>  <at>  -78,6 +78,7  <at>  <at>  struct bcom_gen_bd_priv {
  	int		initiator;
  	int		ipr;
  	int		maxbufsize;
+	u32    *microcode;
  };

 <at>  <at>  -104,6 +105,7  <at>  <at>  bcom_gen_bd_rx_init(int queue_len, phys_
  	priv->initiator	= initiator;
  	priv->ipr	= ipr;
  	priv->maxbufsize = maxbufsize;
+	priv->microcode = bcom_gen_bd_rx_task;
(Continue reading)

Permalink | Reply | 8 comments |

Gmane