On Jul 25, 2008, at 3:41 PM, Rune Torgersen wrote:
From: Arnd Bergmann [mailto:[EMAIL PROTECTED]
On Thursday 17 July 2008, Rune Torgersen wrote:
Arnd Bergmann wrote:
So again, nothing conclusive. I'm running out of ideas.
Is the syscall path different or the same on ppc and powerpc?
Any dif
> From: Arnd Bergmann [mailto:[EMAIL PROTECTED]
> On Thursday 17 July 2008, Rune Torgersen wrote:
> > Arnd Bergmann wrote:
> > > So again, nothing conclusive. I'm running out of ideas.
> >
> > Is the syscall path different or the same on ppc and powerpc?
> > Any differences in the task switching,
On Thursday 17 July 2008, Rune Torgersen wrote:
> Arnd Bergmann wrote:
> > So again, nothing conclusive. I'm running out of ideas.
>
> Is the syscall path different or the same on ppc and powerpc?
> Any differences in the task switching, irq handling or page fault
> handling?
>
It's all differen
Arnd Bergmann wrote:
> So again, nothing conclusive. I'm running out of ideas.
Is the syscall path different or the same on ppc and powerpc?
Any differences in the task switching, irq handling or page fault
handling?
___
Linuxppc-dev mailing list
Linux
On Thursday 17 July 2008, Rune Torgersen wrote:
> Arnd Bergmann wrote:
> > Seeing more hits in handle_mm_fault suggests that you have
> > a higher page fault rate. A trivial reason for this might
> > be that the amount of memory was misdetected in the new
> > code (maybe broken device tree). What i
Arnd Bergmann wrote:
> Seeing more hits in handle_mm_fault suggests that you have
> a higher page fault rate. A trivial reason for this might
> be that the amount of memory was misdetected in the new
> code (maybe broken device tree). What is the content of
> /proc/meminfo after a fresh boot?
Power
Arnd Bergmann wrote:
> Seeing more hits in handle_mm_fault suggests that you have
> a higher page fault rate. A trivial reason for this might
> be that the amount of memory was misdetected in the new
> code (maybe broken device tree). What is the content of
> /proc/meminfo after a fresh boot?
I al
On Thursday 17 July 2008, Rune Torgersen wrote:
> Arnd Bergmann wrote:
> > If you can't get it to work, readprofile(1) is a much simpler
> > tool, both in what it can do and what it requires you to do.
>
> One thing that pops out is that handle_mm_fault uses twice as many
> ticks in arch/powerpc.
Arnd Bergmann wrote:
> If you can't get it to work, readprofile(1) is a much simpler
> tool, both in what it can do and what it requires you to do.
One thing that pops out is that handle_mm_fault uses twice as many ticks
in arch/powerpc.
Top 20 calls from readprofile
2.6.25 arch/ppc
305993 total
On Wednesday 16 July 2008, Rune Torgersen wrote:
> I did run oprofile, but I could not figure out how to get it to show me
> where in the kernel it was spending time. It showed that a lot of time
> was spent in vmlinux, but not anything specific. I probably just don't
> know how to set up or run op
Arnd Bergmann wrote:
> Ok, I think this could be related mostly to two changes:
>
> * In 2.6.23, the process scheduler was replaced, the new one
> is the CFS,
> the 'completely fair scheduler'. This has changed a lot of data.
> To verify this, you could check out a git version just before and
> ju
On Wednesday 16 July 2008, Rune Torgersen wrote:
> Turns out the story is no so simple.
> I redid the test wih all versions of arch/ppc from 2.6.18 to 2.6.26, and
> also arch/powerpc (2.6.24 and 25, 26 doesn't compile because of binutil
> issues)
>
> This time I made very sure that the tests were
Arnd Bergmann wrote:
> On Tuesday 15 July 2008, Rune Torgersen wrote:
>> Using arch/ppc I got a 2.6.25 kernel to boot, and the kernel compile
>> test I did is almost identical (within 1%) of what the arch/powerpc
>> 2.6.25 did, so it seems to be a difference between 2.6.18 and 2.6.25
>> (I'll see i
On Tuesday 15 July 2008, Rune Torgersen wrote:
> Using arch/ppc I got a 2.6.25 kernel to boot, and the kernel compile
> test I did is almost identical (within 1%) of what the arch/powerpc
> 2.6.25 did, so it seems to be a difference between 2.6.18 and 2.6.25
> (I'll see if I can find an exact versi
> * Maybe there is a kernel version that supports your hardware in both
> arch/ppc/ and arch/powerpc. In that case, you could see if
> the platform
> change had an impact.
Using arch/ppc I got a 2.6.25 kernel to boot, and the kernel compile
test I did is almost identical (within 1%) of what the a
> 9919_unit Linux 2.6.25 powerpc-linux-gnu 4343232
> > 1. 1
> > 9919_unit Linux 2.6.18 powerpc-linux-gnu 4453232
> > 1.0100 1
>
> Hmm, processor MHz is off by 11/445
I noticed that.
> And memory latency is off 13/500.
>
> That sounds like it will be 16/66
On Tue Jul 15 02:34:03 EST 2008, Rune Togersen wrote:
We are looking into switching kernels from 2.6.18 (ppc) to 2.6.25
(powerpc).
I have been trying to run some benchmarks to see how the new kernel
compares to the old one.
So far it is performing worse.
One test I ran was just compiling a 2.6.
> This is certainly significant, but a lot has happened between the two
> versions. I few ideas:
>
> * compare some of the key configuration options:
> # CONFIG_DEBUG_*
> # CONFIG_PREEMPT*
> # CONFIG_NO_HZ
> # CONFIG_HZ
2.6.25:
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not
On Monday 14 July 2008, Rune Torgersen wrote:
> Context switching - times in microseconds - smaller is better
>
> Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
> ctxsw ct
Hi
We are looking into switching kernels from 2.6.18 (ppc) to 2.6.25
(powerpc).
I have been trying to run some benchmarks to see how the new kernel
compares to the old one.
So far it is performing worse.
One test I ran was just compiling a 2.6.18 kernel on the system.
The .25 performed 5 to 7 %
20 matches
Mail list logo
