Active Topics
-
Firefox with Leste (5)
to Maemo 7 / Leste by teroyk - 4 days, 7 hrs ago -
Handbook (2)
to Maemo 7 / Leste by teroyk - 5 days, 7 hrs ago - more...
| The Following User Says Thank You to DrWilken For This Useful Post: | ||
|
2010-07-28
, 18:31
|
|
Posts: 1,258 |
Thanked: 672 times |
Joined on Mar 2009
|
#22
|
Why would they use noop? The N900 doesn't have an SSD, and the flash in it behaves nothing like an SSD. noop is probably not that good of an idea..
Besides, you're talking about disk schedulers while the original poster was talking about the CPU scheduler...
Besides, you're talking about disk schedulers while the original poster was talking about the CPU scheduler...
|
|
2010-07-28
, 18:35
|
|
Posts: 515 |
Thanked: 266 times |
Joined on Nov 2009
@ Oelsted, Denmark
|
#23
|
Originally Posted by shadowjk
http://en.wikipedia.org/wiki/Noop_scheduler
Why would they use noop? The N900 doesn't have an SSD, and the flash in it behaves nothing like an SSD. noop is probably not that good of an idea..
"NOOP scheduler is best used with solid state devices such as flash memory or in general with devices that do not depend on mechanical movement to access data"
Originally Posted by shadowjk
That's why I wrote NEVERMIND...
Besides, you're talking about disk schedulers while the original poster was talking about the CPU scheduler...
| The Following User Says Thank You to DrWilken For This Useful Post: | ||
|
|
2010-07-28
, 18:36
|
|
Posts: 52 |
Thanked: 55 times |
Joined on Dec 2009
|
#24
|
Originally Posted by DrWilken
hehe. No worries!
EDIT - NEVERMIND!BFS isn't an I/O scheduler (guess I forgot that somewhere along the road)... I still wonder why CFQ is used instead of noop...
What advantage is there to using noop?
The popular Android device kernel from http://wiki.cyanogenmod.com uses the BFQ IO scheduler: http://lwn.net/Articles/275978/ I was considering incorporating this patch. Cause, hey, the Android kids presumably liked it for a reason.
|
|
2010-07-28
, 18:50
|
|
Posts: 515 |
Thanked: 266 times |
Joined on Nov 2009
@ Oelsted, Denmark
|
#25
|
Originally Posted by coreyoconnor
IF (I don't know) flash devices have their own mechanism for handling read/writes there's no need for CFQ to do it for them.
What advantage is there to using noop?
That's the way SSD's function (AFAIK), but I'm not sure about flash. Maybe shadowjk knows...
Lot's of sites mention using noop for flash based drives:
http://stackoverflow.com/questions/1...-i-o-scheduler:
... noop is often the best choice for memory-backed block devices (e.g. ramdisks) and other non-rotational media (flash) where trying to reschedule I/O is a waste of resources ...
... The noop scheduler is suitable for devices where there are no performance penalties for seeks. Examples of such devices are ones that use flash memory...
Originally Posted by coreyoconnor
It's worth a try...
The popular Android device kernel from http://wiki.cyanogenmod.com uses the BFQ IO scheduler: http://lwn.net/Articles/275978/ I was considering incorporating this patch. Cause, hey, the Android kids presumably liked it for a reason.
Last edited by DrWilken; 2010-07-28 at 18:56. Reason: bad spelling... ;)
|
|
2010-07-29
, 10:53
|
|
Posts: 1,258 |
Thanked: 672 times |
Joined on Mar 2009
|
#26
|
Well even the term "seek" is wrong for flash.. And ramdisks behave *completely* differently..
To simplify: when writing, a flash drive behaves alot like a slow harddrive from 1995
when reading, it's more like "seeks are free"..
In other words, "seeks" matter if there's any write activity going on, and there cfq can help a bit What's more, a 256k sequential write can be as slow/fast as a 4k write, depending on the access patterns. Unfortunately no schedulers are flash aware. Yes, some are SSD aware, but SSDs have big friggin ARM processors and heaps of RAM to reorder data so that the weak parts of flash performance is hidden..
To simplify: when writing, a flash drive behaves alot like a slow harddrive from 1995
when reading, it's more like "seeks are free"..
In other words, "seeks" matter if there's any write activity going on, and there cfq can help a bit What's more, a 256k sequential write can be as slow/fast as a 4k write, depending on the access patterns. Unfortunately no schedulers are flash aware. Yes, some are SSD aware, but SSDs have big friggin ARM processors and heaps of RAM to reorder data so that the weak parts of flash performance is hidden..
| The Following 3 Users Say Thank You to shadowjk For This Useful Post: | ||
|
|
2010-07-29
, 14:03
|
|
Posts: 515 |
Thanked: 266 times |
Joined on Nov 2009
@ Oelsted, Denmark
|
#27
|
Originally Posted by shadowjk
I did know that they had buffers/cache (RAM), but I had no idea that SSD's had an onboard CPU...
SSDs have big friggin ARM processors and heaps of RAM to reorder data so that the weak parts of flash performance is hidden..
For anyone interested more info here...
Last edited by DrWilken; 2010-07-29 at 14:11.
|
|
2010-07-29
, 14:20
|
|
Posts: 161 |
Thanked: 85 times |
Joined on Feb 2010
|
#28
|
I just leave this here for who is thinking wat?
don't mind me
http://ck.kolivas.org/patches/bfs/sched-BFS.txt
don't mind me
http://ck.kolivas.org/patches/bfs/sched-BFS.txt
| The Following 3 Users Say Thank You to erniadeldesktop For This Useful Post: | ||
|
|
2010-07-29
, 18:37
|
|
Posts: 317 |
Thanked: 787 times |
Joined on Oct 2009
@ Krakow, Poland
|
#29
|
I have just installed and tested it. The first thing that I have noticed is that vibration after touching the screen can take be up to 1 second long on high loads. On non-BFS kernels vibration was always very short (and on high load there was no vibration at all as device was not responding at all). I did a test with app manager - and it was certainly better than non-BFS because even with high load and paging I was able to interact with UI. But it was far from smooth. So far it is good. If I find anything interesting I will post here.
| The Following 3 Users Say Thank You to dwaradzyn For This Useful Post: | ||
|
|
2010-07-29
, 19:11
|
|
Posts: 1,258 |
Thanked: 672 times |
Joined on Mar 2009
|
#30
|
Originally Posted by DrWilken
I did know that they had buffers/cache (RAM), but I had no idea that SSD's had an onboard CPU...
For anyone interested more info here...
Intrestng stuff, but the most crucial:
A January 2009 review of the market by technology reviewer Tom's Hardware concluded that comparatively few of the tested devices showed acceptable I/O performance, with several disappointments
In particular, operations that require many small writes, such as log files, are particularly badly affected on some devices, potentially causing the entire host system to freeze for periods of up to one second at a time.
Intel needed to add a big ARM processor and megabytes of ram, not for buffer/cache, but for essentially running a log structured filesystem ontop of the raw flash
The amount of resources they needed to make it fast all the time wont fit in a SD/mmc for quite some years yet
| The Following 3 Users Say Thank You to shadowjk For This Useful Post: | ||
On any other Linux variant You can change it by using /sys/block/<block-device>/queue/scheduler...
I just had a look:
BTW - I'm using the power kernel (.37).
EDIT - NEVERMIND!
Christian Wilken - tux-POWER.dk!
... May the Source be with You ...
Last edited by DrWilken; 2010-07-28 at 18:29.