Re: [parisc-linux] Latest palinux crash

From: Joel Soete <soete.joel@tiscali.be>
To: John David Anglin <dave@hiauly1.hia.nrc.ca>
Cc: carlos@systemhalted.org, parisc-linux@parisc-linux.org
Subject: Re: [parisc-linux] Latest palinux crash
Date: Mon, 08 Aug 2005 19:29:26 +0000	[thread overview]
Message-ID: <42F7B296.7020504@tiscali.be> (raw)
In-Reply-To: <200507261637.j6QGb4vs008289@hiauly1.hia.nrc.ca>

John David Anglin wrote:
>>(but I could never experiment it because of it's so big size: iirc about 60Mb for the 2.4 and this time my dump (swap) area was too 
> 
> 
> That doesn't make sense.  The addition of debug info shouldn't change
> the size of a core dump.  It's the code and data needed to actual do
> the dump that increases the kernel size.
> 
Ah sorry for confusion but the two things are not related and not related to coredump size:
	o first the executable vmlinux was very big
	  (as plao doesn't yet support a compressed vmlinuz it was
	   hard to find a place at this time to copy it to an easy
	   access path /boot a dedicated slice of only 30Mb
	   but now increased to 128 for this reason ;-)
	o oth the ram of the system 2Gb (N4k) and only 256Mb of swap
	  also used to dump the kernel core; even thought linux didn't
	  use the all ram but well regualry about 1.4Gb
	  (or I would have to sacrify another fs?)

> 
>>>I recommend building
>>>with -O1 instead of -O2.
>>>
>>
>>mmm could it not be too much invasive?
> 
> 
> I don't think so.  Optimization shouldn't change code behavior. While
Agreed.

> it's true that a change in execution speed might break some realtime
> code, if this happens in linux, it's probably a bug.
> 
> 
>>I mean we are going to change completely the insn flow and btw the time diagram as I experiment:
>>some weeks ago, I was working on ccio-dma for 64bit kernel on a d380 on which I noticed a dramtic slow down of the boot (more then 
>>an hour in place of 5 min for its 32bit twin).
> 
> 
> In most cases, there's only a small change in execution speed and sometimes
> -O1 is faster.  The above change is abnormally large and suggests that a
> major chunk of code is being optimized away.

Ah also, I missed but I doubt in this case: just change a const determining the number of printk change the behaviour, though.

> 
> Dave

Thanks,
	Joel
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux