Active Topics
-
The N900 is now 15 years old! (6)
to Nokia N900 by Macros - 1 day, 3 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 1 day, 16 hrs ago -
n770 youtube video (0)
to General by nmdv - 5 days, 15 hrs ago - more...
|
2012-06-13
, 16:33
|
|
Posts: 204 |
Thanked: 423 times |
Joined on Jan 2011
|
#112
|
Originally Posted by Alfred
Well, I finally understand wtat @freemangordon meant by “kernel-power-setting v14 is incompatible with kernel-cssu”.
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?
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.
Custom NOLO Splash, USB and R&D icons.
Last edited by hxka; 2012-06-13 at 16:49.
| The Following 5 Users Say Thank You to hxka For This Useful Post: | ||
|
|
2012-06-13
, 18:34
|
|
Posts: 1,203 |
Thanked: 3,027 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.
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: | ||
|
|
2012-06-14
, 22:18
|
|
Posts: 2,076 |
Thanked: 3,268 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.
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: | ||
|
|
2012-06-14
, 22:28
|
|
Posts: 2,076 |
Thanked: 3,268 times |
Joined on Feb 2011
|
#115
|
Originally Posted by freemangordon
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: | ||
|
|
2012-06-14
, 22:36
|
|
Posts: 2,076 |
Thanked: 3,268 times |
Joined on Feb 2011
|
#116
|
Originally Posted by freemangordon
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)
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
Last edited by szopin; 2012-06-14 at 23:02. Reason: not a native speaker, sorry, fixed for reading comprehension hopefully
| The Following 2 Users Say Thank You to szopin For This Useful Post: | ||
|
|
2012-06-15
, 06:20
|
|
Posts: 112 |
Thanked: 92 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
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: | ||
|
|
2012-06-15
, 06:56
|
|
Posts: 3,074 |
Thanked: 12,960 times |
Joined on Mar 2010
@ Sofia,Bulgaria
|
#118
|
Originally Posted by szopin
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
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.
. 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)
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
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; 2012-06-15 at 07:00.
| The Following 17 Users Say Thank You to freemangordon For This Useful Post: | ||
|
|
2012-06-15
, 10:54
|
|
Posts: 346 |
Thanked: 271 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
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: | ||
|
|
2012-06-15
, 11:21
|
|
Posts: 1,523 |
Thanked: 1,997 times |
Joined on Jul 2011
@ not your mom's FOSS basement
|
#120
|
Hmm, swap on rootfs and everything else on EMMC.... IIRC it was nolo who couldn't can't handle such a setup.
| The Following 3 Users Say Thank You to don_falcone For This Useful Post: | ||
 |
| Tags |
| code size, dinosaurs, fmg ftw!, fmg.da.king, performance, thumb, thumb life |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 12:27.
Last edited by Raimu; 2012-06-13 at 16:26.