performance testing of UNWIND kernel option

2011-03-08 Thread Gennady Kupava
Hi, list.

Today I noticed the following change in SHR:
http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=1516588acd3c4b4dd4add71d06ab8ce0d1bafa02
 (by Denis 'GNUtoo' Carikli ) and decided to lmbench it.

Here are results: http://www.bsdmn.com/lmbench/unwind_summary.txt

You can see comparison of:

34def -> kernel with CONFIG_FRAME_POINTER
unwind -> kernel with CONFIG_ARM_UNWIND
default -> for reference, old debugging kernel

The unwind option provide clear benefit of 5%-10% in almost every area.

Nice spot Denis!

Gennady.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: performance testing of UNWIND kernel option

2011-03-08 Thread Rui Miguel Silva Seabra

Em 08-03-2011 14:01, Gennady Kupava escreveu:

Hi, list.

Today I noticed the following change in SHR:
http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=1516588acd3c4b4dd4add71d06ab8ce0d1bafa02
 (by Denis 'GNUtoo' Carikli) and decided to lmbench it.

Here are results: http://www.bsdmn.com/lmbench/unwind_summary.txt

You can see comparison of:

34def ->  kernel with CONFIG_FRAME_POINTER
unwind ->  kernel with CONFIG_ARM_UNWIND
default ->  for reference, old debugging kernel

The unwind option provide clear benefit of 5%-10% in almost every area.

Nice spot Denis!


It does feel faster!

OpenMoko Freerunner, probably the only "obsolete" phone that keeps 
getting better :)


Rui

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: performance testing of UNWIND kernel option

2011-03-08 Thread Martix
Hi,
thanks for comparison.
I miss test with both CONFIG_ARM_UNWIND and CONFIG_FRAME_POINTER
disabled, theoreticaly it could be faster. Anyway, why regular user
(no developer, nor tester) needs to have CONFIG_ARM_UNWIND or
CONFIG_FRAME_POINTER enabled? I suggest to disable CONFIG_ARM_UNWIND
in stable kernel images. Stable I mean (in this case) kernel versions
which is well tested in SHR-t and stable revisions of Qt Moko.

Thanks Denis and Gennady.

Martin 'Martix' Holec
openmoko.cz/openmobility.cz


2011/3/8 Gennady Kupava :
> Hi, list.
>
> Today I noticed the following change in SHR:
> http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=1516588acd3c4b4dd4add71d06ab8ce0d1bafa02
>  (by Denis 'GNUtoo' Carikli ) and decided to lmbench it.
>
> Here are results: http://www.bsdmn.com/lmbench/unwind_summary.txt
>
> You can see comparison of:
>
> 34def -> kernel with CONFIG_FRAME_POINTER
> unwind -> kernel with CONFIG_ARM_UNWIND
> default -> for reference, old debugging kernel
>
> The unwind option provide clear benefit of 5%-10% in almost every area.
>
> Nice spot Denis!
>
> Gennady.
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: performance testing of UNWIND kernel option

2011-03-08 Thread Martix
Ok, it is reasonable to keep CONFIG_ARM_UNWIND enabled when this
option have no practical effect on performance or latency in kernel.
So, keep it enabled. :-)

Martin 'Martix' Holec
openmoko.cz / openmobility.cz

2011/3/8 Gennady Kupava :
> Hi,
>
> 1. UNWIND do not influence performance, so enabling it should make no
> harm (according to kernel doc, i trust em 99.9%).
> 2. ability to get stack trace is widely accepted bare minimum of debug
> info, this is info is _really_ (not like other hardly usable debugging
> stuff were enabled earlier) invaluable for fixing and identifying
> problems found.
>
> So, no reason remove both. It is even kind of switch in kernel config
> turn on UNWIND -> FRAME_POINTER turns off. No affect on performance, add
> ability to identify problem -> must have IMO.
>
> Gennady.
>
> В Втр, 08/03/2011 в 16:40 +0100, Martix пишет:
>> Hi,
>> thanks for comparison.
>> I miss test with both CONFIG_ARM_UNWIND and CONFIG_FRAME_POINTER
>> disabled, theoreticaly it could be faster. Anyway, why regular user
>> (no developer, nor tester) needs to have CONFIG_ARM_UNWIND or
>> CONFIG_FRAME_POINTER enabled? I suggest to disable CONFIG_ARM_UNWIND
>> in stable kernel images. Stable I mean (in this case) kernel versions
>> which is well tested in SHR-t and stable revisions of Qt Moko.
>>
>> Thanks Denis and Gennady.
>>
>> Martin 'Martix' Holec
>> openmoko.cz/openmobility.cz
>>
>>
>> 2011/3/8 Gennady Kupava :
>> > Hi, list.
>> >
>> > Today I noticed the following change in SHR:
>> > http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=1516588acd3c4b4dd4add71d06ab8ce0d1bafa02
>> >  (by Denis 'GNUtoo' Carikli ) and decided to lmbench it.
>> >
>> > Here are results: http://www.bsdmn.com/lmbench/unwind_summary.txt
>> >
>> > You can see comparison of:
>> >
>> > 34def -> kernel with CONFIG_FRAME_POINTER
>> > unwind -> kernel with CONFIG_ARM_UNWIND
>> > default -> for reference, old debugging kernel
>> >
>> > The unwind option provide clear benefit of 5%-10% in almost every area.
>> >
>> > Nice spot Denis!
>> >
>> > Gennady.
>> >
>> >
>> > ___
>> > Openmoko community mailing list
>> > community@lists.openmoko.org
>> > http://lists.openmoko.org/mailman/listinfo/community
>> >
>
>
>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community