Page 12 of 155 « First 21011 12 131422 Last »
Reply
Thread Tools Search this Thread
Raimu is offline Raimu
06-13-2012 , 12:23 PM
Posts: 102 | Thanked: 123 times | Joined on Nov 2011 @ Oulu, Finland
#111
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.
Last edited by Raimu; 06-13-2012 at 12:26 PM.
 

The Following 3 Users Say Thank You to Raimu For This Useful Post:
hxka is offline hxka
06-13-2012 , 12:33 PM
Posts: 168 | Thanked: 331 times | Joined on Jan 2011
#112
Originally Posted by Alfred View Post
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?
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.
__________________
Custom NOLO Splash, USB and R&D icons.
Last edited by hxka; 06-13-2012 at 12:49 PM.
 

The Following 5 Users Say Thank You to hxka For This Useful Post:
Android_808 is offline Android_808
06-13-2012 , 02:34 PM
Posts: 308 | Thanked: 343 times | Joined on Dec 2010
#113
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.
 

The Following 4 Users Say Thank You to Android_808 For This Useful Post:
szopin is offline szopin
06-14-2012 , 06:18 PM
Posts: 961 | Thanked: 938 times | Joined on Feb 2011
#114
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.
 

The Following 3 Users Say Thank You to szopin For This Useful Post:
szopin is offline szopin
06-14-2012 , 06:28 PM
Posts: 961 | Thanked: 938 times | Joined on Feb 2011
#115
Originally Posted by freemangordon View Post
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)

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.
 

The Following User Says Thank You to szopin For This Useful Post:
szopin is offline szopin
06-14-2012 , 06:36 PM
Posts: 961 | Thanked: 938 times | Joined on Feb 2011
#116
Originally Posted by freemangordon View Post
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
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)
Last edited by szopin; 06-14-2012 at 07:02 PM. Reason: not a native speaker, sorry, fixed for reading comprehension hopefully
 

The Following 2 Users Say Thank You to szopin For This Useful Post:
nkirk is offline nkirk
06-15-2012 , 02:20 AM
Posts: 112 | Thanked: 90 times | Joined on Nov 2010
#117
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
 

The Following User Says Thank You to nkirk For This Useful Post:
freemangordon is online now freemangordon
06-15-2012 , 02:56 AM
Posts: 2,180 | Thanked: 8,291 times | Joined on Mar 2010 @ Sofia,Bulgaria
#118
Originally Posted by szopin View Post
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.
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.

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)
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.
__________________
Never fear. I is here.

720p video support on N900,SmartReflex on N900,Keyboard and mouse support on N900
Nothing is impossible - Stable thumb2 on n900

Community SSU developer
kernel-power developer and maintainer
Last edited by freemangordon; 06-15-2012 at 03:00 AM.
 

The Following 17 Users Say Thank You to freemangordon For This Useful Post:
Megaltariak is offline Megaltariak
06-15-2012 , 06:54 AM
Posts: 345 | Thanked: 260 times | Joined on Jan 2010
#119
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
 

The Following 5 Users Say Thank You to Megaltariak For This Useful Post:
don_falcone's Avatar
don_falcone is offline don_falcone
06-15-2012 , 07:21 AM
Posts: 1,468 | Thanked: 1,894 times | Joined on Jul 2011 @ not your mom's basement
#120
Hmm, swap on rootfs and everything else on EMMC.... IIRC it was nolo who couldn't can't handle such a setup.
__________________
Thinking about switching to a newer device? Not sure if your favorite Maemo/Harmattan application has an equivalent or substitution? Android sucks way less than people around here shout. Check my personally-made substitution list!
 

The Following 3 Users Say Thank You to don_falcone For This Useful Post:
Reply
Page 12 of 155 « First 21011 12 131422 Last »

Tags
code size, dinosaurs, fmg.da.king, performance, thumb, thumb life

« Previous Thread | Next Thread »
Thread Tools Search this Thread
Search this Thread:

Advanced Search

 
Forum Jump


All times are GMT -4. The time now is 04:41 PM.

Contact Us - Home - Archive - Top