New significant speedups coming to FreeRunner

Denis Johnson denis.johnson at gmail.com
Mon Jan 11 01:01:15 CET 2010


Thanks to Radek, I indeed also needed to download an untar the modules.

All good, great work.

On Sun, Jan 10, 2010 at 10:59 PM, Denis Johnson <denis.johnson at gmail.com> wrote:
> Good work,
>
> Do I only need the .bin or the config and modules also. I have tried
> just the .bin using qtMoko v16 image and it boots quite quickly to qt
> ui then cycles to black screen with blinking cursor then after some
> time back to qt screen then back to black screen. etc
>
> cheers Denis
>
> On Sat, Jan 9, 2010 at 4:23 AM, Timo Jyrinki <timo.jyrinki at gmail.com> wrote:
>> Hi,
>>
>> Just FYI to the community list, as slowness has been one of the
>> biggest problems with Neo. Quite nice speedups are coming:
>>
>> http://lists.openmoko.org/pipermail/openmoko-kernel/2010-January/010811.html
>> (performance testing by Gennady Kupava)
>>
>> Apparently, and unfortunately, no-one had really questioned Om Inc:s
>> (who mainly did the kernel work back in the days of the still mostly
>> used 2.6.29) choices of kernel configuration. Disabling kernel debug
>> features and pre-empt has resulted eg. these kind of improvements
>> (from IRC, #openmoko-fi):
>> - boot time 68.5% of original
>> - "apt-cache search nano" 20s -> 14.8s
>> - "emacs -f kill-emacs" 3.8s -> 2.2s
>>
>> These configuration changes are not yet in andy-tracking (the 2.6.29
>> kernel still being used in most distros), I don't know what's the
>> situation in the new om-2.6.32 branch. Together with the quite recent
>> commit from Thomas White that doubled theoretical glamo speeds (in
>> practice at least 20% in general), I feel that Neo FreeRunner is not
>> anymore "terribly slow", but only "slow" by today's standards, which
>> is quite an improvement. Especially after having been used to the
>> "terribly slow" general behavior ;)
>>
>> Please tell if some distro happened to have those disabled already,
>> and if someone knew about these speedups via the options already - and
>> please arrange a commit to git.openmoko.org next time! Anyway, this
>> all goes to show that in a project with limited resources like
>> Openmoko, especially now that it's completely in the hands of the
>> community when it comes to Neo FreeRunner development, you have to
>> have the courage to question anything "suspicious" etc. you are
>> seeing, not trusting that someone has actually optimized something to
>> the extent assumed.
>>
>> If you want to have a quick grab of the new kernel for Debian (or any
>> distro that loads uImage from a file), I put my compilation of kernel
>> and modules to http://users.tkk.fi/~tajyrink/moko/kernel_20100108_nodebug_nopreempt/
>>
>> -Timo, wishing everyone a speedier new year
>>
>> _______________________________________________
>> Openmoko community mailing list
>> community at lists.openmoko.org
>> http://lists.openmoko.org/mailman/listinfo/community
>>
>



More information about the community mailing list