Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Freemangordon - that's magic. You've baws the size of spacehoppers, mate - the size of spacehoppers.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

thanx for freemangordon for making cssu thumb.
there is some issue with rootfs i had added an screenshot of conky.just checkit .does any one can help in moving lib files from rootfs to make some space in rootfs? it will be good if the cssu thumb uses less rootfs.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Never tried it, looks promising. Unfortunately jonwil is nowhere to be seen these days. BTW I will repeat - I will appreciate any help I can get as this is not a project for one man (even if he is freemangordon@TMO :P )

@don_falcone and others: could you try to build that iozone or whatever it is called and do some benchmarking

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Sure it will be good, but I still need some hard data before making the decision to return Qt libs back to /opt. And have in mind more packages are thumb-compiled, more free space on rootfs.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

microb-engine is a totally different project, If it turned out it is not easy to be thumb-compiled then it will remain ARM.

Don't ask me about thumb inclusion in CSSU -testing and -stable flavors, ask the maintaners (MohammadAG and merlin1991), it is up to them to decide. On the other hand the packages are made in such a way, that next version of CSSU-T will overwrite -thumb version if one don't wait until respective -thumb version is out.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Amazing. @freemangordon, I love you!
I didn't hae any problems with kernel-power-settings during installation, maybe because I used apt-get, not HAM.
For removing there is an option: aptitude handle dependencies waay better that apt-get.
As for Qt libs, I did sort of test: I have run some Qt apps on N900 right after reboot, and it seems there is no visible difference in time of loading between optified and non-optified Qt libs (We aren't running after picoseconds, right?). So I am voting for optified Qt libs, as they at least saving space on rootfs, though I'm not needing it, having 33.3M free even with non-optified Qt libs.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

im also getting ''internal error application closed'' error in conversation, microb and photo quiet lot..
sometimes my n900 even freeze when using qwerty..

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

As you people like to use experimental software - can you confirm that you are NOT using the updated version of libraries (compiled by marmistrz)? These libraries cause similar errors and we should not mess them up with this CSSU-thumb if we want to spot problems.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

freemangordan: if someone can provide detailed up to date insructions on setting up a build environent and emulator in Vista I'd be happy to have a look at microb. Unfortunately my only Linux device at the moment, other than N900, is an Eee 1000, and I don't fancy waiting for it to compile on there.

Might be worth PM'ing romaxa to see if he can provide any more source code or help with build set up.

I've had a look at microb-engine before but never got round to setting up and building it. I was instead assessing the feasibility of rebasing it on Firefox 7 or 8. Some patches need modifying slightly, some there are newer versions elsewhere.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Attached. Build with MADDE (install-madde-0.7.48-linux-x86_64.sh) and their current source (iozone3_408.tar):

Had no time to play around much with it, though but it runs. EDIT: their help is here (Google Docs), and some example usage is explained here

EDIT 2:
Still digging through the examples and manual. A (albeit "temporary") command line would be:

-l indicates the minimum number of iozone processes that should be started: 2
-u indicates the maximum number of iozone processes that should be started: 2
-F should contain multiple values. i.e If we specify 2 in both -l and -u, we should have two filenames here. Please note that only the mount points need to exists. The file specified in the -F option doesn’t need to exists, as iozone will create this temporary file during the testing. In the above example, the mount points are /usr, and /opt. The files tmp1 and tmp2 will be automatically created by iozone for testing purpose.

As i dont know a good sector size etc. there's plenty of optimization room. note that option DIRECT IO (-I) seems not supported, as i got

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Well, according to some benchmarking I made with iozone, rootfs is definitely faster in reading than /opt.

Attached are the results of the following commands:

./iozone -f /opt/libQtWebKit.so.4 -a -+E -i 1 -i 2 -i 3 -i 5 -i 7 for opt.txt

./iozone -f /usr/lib/libQtWebKit.so.4 -a -+E -i 1 -i 2 -i 3 -i 5 -i 7 for rootfs.txt

the first column is data size in KB, the second is record len, the others are reading speeds in KB/s

I was not able to run iozone in sync mode with file in rootfs, it gives "invalid operation" error, so those results are not the real read transfer rates from the flash, but still are a good indication.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

@freemangordon
does cssu thumb consumes less battery power?

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Which one?
-+r
Enable O_RSYNC and O_SYNC for all I/O testing.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

...that's what he said. ;)

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

@freemangordon, recompiling (open) packages with thumb is manual work. What about to wait for our thumb repository in OBS and use patched debhleper scripts which automatically compile binaries in thumb mode and also auto add dependency on cssu-kernel/thumb-kernel?

See my idea from irc log: http://mg.pov.lt/maemo-ssu-irclog/%2...06-08T23:07:15

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Ha ha, that log is alone for the "debate" between Estel_ and jacekowski funny to read.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

While that could work for packages in -extras, it won't work for cssu stuff. And core system components (cssu stuff) are the major goal for thumb, as they usually stay resident in memory. And for packages which have assembly code an additional manual work is needed to make them thumb compatible. Moreover some of the packages recognise "thumb" in DEB_BUILD_OPTIONS (modest for example :p ) and add the appropriate compiler flags, so no secial debhelper is needed, while the others does not have a way to affect compiler flags from debian/rules.

@don_falcone: "-+r" seems to not work either, as it affects only writes :(

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Hmm, according to:

Nokia-N900:~# time cat /root/libQtGui.so.4.7.4 > /dev/null
real 0m 5.52s
user 0m 0.00s
sys 0m 5.30s

Nokia-N900:~# time cat /opt/libQtGui.so.4.7.4 > /dev/null
real 0m 4.97s
user 0m 0.03s
sys 0m 1.02s

I should move Qt back to /opt ASAP :).

Any thoughts?

Note:
libQtGui.so.4.7.4 is 95510528 bytes long (QtGui debug symbols)

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

I have no problems with it, it works just fine.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Hmm, there is a cache. These times could be wrong, unless you remounted filesystems just before reading.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

cache that holds 2x95MB? I doubt. And you failed to see sys time (that 5 seconds spent in decompressing rootfs contents)

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

"When ‘time’ command is executed without the complete path (/usr/bin/time), then its the built-in ‘time’ command of the bash shell that is executed."
Anyway, i value my available / space more than some secs during loading.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Does it matter which exactly "time" is executed?

Anyway, it seems it was a mistake to move Qt to rootfs in terms of both speed and free rootfs space, will wait some comments from szopin and whoever wants to comment on that and most probably will revert Qt location back to /opt

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

I know the intention of moving QT libs to rootfs was to improve performance, but once they're loaded into RAM surely it makes no difference. If there is already a QT app open, then the next should only need to load any additional libraries. For this reason I'd rather save space on rootfs.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Why is there a /usr/share/applications/hildon/kernel-cssu-uninstall.desktop which being pressed installs stock kernel producing unbootable device?

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

i might ask smth stupid, if so tell me. But how can i install kp-settings without also installing kp, flasher, modules. Wouldn't cssu kernel be enough for kp-settings?

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

dpkg --ignore-depends=kernel-power-settings kernel-settings.deb
I think something like that does the trick, check the name of stuff I have typed :)

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

i am not experiencing any adv after update. can u plz tel me what sort of update i should be experiencing?

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Well, AFAIK it does not work like that. We can never get rid of the swap. And (again) AFAIK the first pages to evict when there is no enough RAM, are executable pages. But when that code page is needed again it is better if it is on the faster media, that way multitasking will be better/smoother. Also have in mind that executable pages NEVER go to swap, so we don't know (at least not easy) what part of the executable code is in RAM, and what part will be read next time it has to be executed. That is the rationale behind my attempt to move Qt to a faster (as I was thinking) storage.

Now it turns out this (rootfs is faster) is an urban legend. Not only that, but it consumes CPU time too, so most probably soon there will be an update which will move Qt back to /opt

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Exactly this.

Go and read OP again.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Before announcing that the NAND is not worth placing things into for quicker loading speed, I think it's necessary to really read up on the implementation of the 256 MB NAND rootfs. Methinks running just a couple of time tests isn't enough -- it's OK to just optify the libs again in the meantime, though, but some anecdotal evidence and a test or two isn't conclusive.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Well, I finally understand wtat @freemangordon meant by “kernel-power-setting v14 is incompatible with kernel-cssu”.
Yes, there is no way (breaking package system isn't a way) to install kernel-power-settings without kernel-power-flasher or kernel-power-bootimg because it depends on any of them.
Instead, kernel-power maintainers should made it depend on virtual package kernel-feature-overclock, which is provided by any of kernel-{power,cssu}-{flasher,bootimg} package. If they had done it from very beginning, there wouldn't be such a problem at that time.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Memory handling mechanics at OS level is not something I'm an expert on, but my somewhat stupid understanding of it is that certain aspects of the libraries can be shared which if the contents are unmodified. Once changed each an application would receive its own copy. The shared data would therefore, depending on page being in RAM, avoid reading the data from disk.


from http://stackoverflow.com/questions/3...rary-in-linux:
The operating system's virtual memory implementation takes care of using the same page of physical memory for multiple processes when the contents are unchanged from what's on-disk, and making physical duplicates of pages at runtime if they're written to. All of this is transparent to your application, which sees a linear 32- or 64-bit address space consisting of nothing but its own code and data.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Sorry, not sure if someone brought this up before but this:
http://www.google.com/url?sa=t&rct=j...V578uGl8MNH9Dw (PDF warning)

ARM vs Thumb vs Thumb2. Performance(speed)-wise ARM trumps (check page 4), size is for thumb 1 and 2. I would love to see iozone benchmarks of course, but thought this might give some background.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Same as comparisons of class 10 vs class 4 SD cards. Random readwrites make all the differnce for something like booting ubuntu. For HD recording none. In different tests you will get different answers. Try reads from rootfs of highly compressed data like binaries/.o's. Totally different results when writing 1010101... sequentially, all kind of algorithms kick in in between your test and actual write(/read). Best method to check is just starting microb as Nokia made it (rootfs) while clocking and/or camcording time. Restart, move to opt, symlink, restart, clock it and camcord it again and compare. No place for placebo bias.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Except for easy test confirming compression is taking place (so probably not an urban legend) I cannot tell much more. As this is very undetailed ground, who knows, maybe there is a HW solution Nokia implemented for compressing rootfs on the go and it should be(is?) faster. I definitely did not say it is slower by using CPU time (probably should have, seems logical), there might be a compression chip doing it (slowness could be introduced by it or by use case, 10kb txt file could go faster maybe, no idea, but microb starts faster for me from opt so that was my conclusion)

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Summary
Thumb-2 core technology is a significant enhancement to the ARM architecture,
which provides performance at higher code densities than previously achievable with
the ARM architecture. In addition, Thumb-2 introduces a number of new features to
further improve program flow, program efficiency and code size. Together these
benefits will enable designers to pack more features into devices while obtaining
improved power and performance characteristics, providing a more complete base
for feature-rich, end-user devices.

^^ quote from Thumb2 pdf.
Hope this clarifies some misconceptions.

/nkirk

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

You're missing my point, it is not about the writes at all, rootfs is much faster on writes, but that does not matter when we're talking about executable code ;). Is is all about the read operations, and there is where rootfs is not only slower, but consumes 90% CPU time to achieve that slowness. BTW the reason i choose 95MB file to do the read test was to get rid of cache/buffers/whatever effects on the speed.

Also have in mind that there is no performance penalty for doing random reads on flash (i.e. /opt) it is only write operations that are affected.

Nah, there is no such thing like compression chip, it is the standard ubifs de/compression and it uses CPU. I definitely say it is slower, as my test ( the "time cat" one) shows the maximum reading speed achieved when there is noone else using the CPU. Imagine what happens with that speed when there are several processes using the CPU.

The case is closed for me, expect a new update (hopefully today) which moves Qt back to /opt.

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

I'm maybe little off-topic here but is it possible to use the 256MO NAND for something other than a compressed rootfs?
Something like an additionnal swap partition, I don't know much about the N900's initial boot process but maybe keep a small UBIFS partition if NOLO is harcoded to boot on it, and load maemo entirely from EMMC (like some already did with microSD card)

I believe that choosing UBIFS instead of standard ext3 was a really bad decision from Nokia, I think they initially wanted Maemo to fit entirely on the small chip so they used a compressed fs.
With PR1.2 Maemo wouldn't fit anymore on the small chip so they decided to "optify" parts of it but they didn't revert rootfs to something more standard (lack of time/developers I presume)

I will test CSSU-thumb as soon as I recieve my spare N900 :)

Re: [ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900
 

Hmm, swap on rootfs and everything else on EMMC.... IIRC it was nolo who couldn't can't handle such a setup.