Page 3 of 31 12 3 4513 Last »
Reply
Thread Tools
DrWilken is offline DrWilken
2010-07-28 , 18:21
Posts: 515 | Thanked: 266 times | Joined on Nov 2009 @ Oelsted, Denmark
#21
It should be fairly easy to change the scheduler *live*...

On any other Linux variant You can change it by using /sys/block/<block-device>/queue/scheduler...

I just had a look:
Code:
N900:~# cat /sys/block/mmcblk0/queue/scheduler 
noop [cfq]
So changing to noop scheduler (BFS isn't there by default) can be done using:
Code:
N900:~# echo noop > /sys/block/mmcblk0/queue/scheduler
N900:~# cat /sys/block/mmcblk0/queue/scheduler 
[noop] cfq
Wonder why they didn't use the noop scheduler by default.

BTW - I'm using the power kernel (.37).

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...
__________________
Christian Wilken - tux-POWER.dk!
... May the Source be with You ...
Last edited by DrWilken; 2010-07-28 at 18:29.
 

The Following User Says Thank You to DrWilken For This Useful Post:
shadowjk is offline shadowjk
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...
 
DrWilken is offline DrWilken
2010-07-28 , 18:35
Posts: 515 | Thanked: 266 times | Joined on Nov 2009 @ Oelsted, Denmark
#23
Originally Posted by shadowjk View Post
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..
http://en.wikipedia.org/wiki/Noop_scheduler

"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 View Post
Besides, you're talking about disk schedulers while the original poster was talking about the CPU scheduler...
That's why I wrote NEVERMIND...
__________________
Christian Wilken - tux-POWER.dk!
... May the Source be with You ...
 

The Following User Says Thank You to DrWilken For This Useful Post:
coreyoconnor is offline coreyoconnor
2010-07-28 , 18:36
Posts: 52 | Thanked: 55 times | Joined on Dec 2009
#24
Originally Posted by DrWilken View Post
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...
hehe. No worries!
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.
 
DrWilken is offline DrWilken
2010-07-28 , 18:50
Posts: 515 | Thanked: 266 times | Joined on Nov 2009 @ Oelsted, Denmark
#25
Originally Posted by coreyoconnor View Post
What advantage is there to using noop?
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.

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 ...
http://www.redhat.com/docs/wp/perfor...uler-noop.html:
... 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...
Google Search...

Originally Posted by coreyoconnor View Post
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.
It's worth a try...
__________________
Christian Wilken - tux-POWER.dk!
... May the Source be with You ...
Last edited by DrWilken; 2010-07-28 at 18:56. Reason: bad spelling... ;)
 
shadowjk is offline shadowjk
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..
 

The Following 3 Users Say Thank You to shadowjk For This Useful Post:
DrWilken is offline DrWilken
2010-07-29 , 14:03
Posts: 515 | Thanked: 266 times | Joined on Nov 2009 @ Oelsted, Denmark
#27
Originally Posted by shadowjk View Post
SSDs have big friggin ARM processors and heaps of RAM to reorder data so that the weak parts of flash performance is hidden..
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...
__________________
Christian Wilken - tux-POWER.dk!
... May the Source be with You ...
Last edited by DrWilken; 2010-07-29 at 14:11.
 
erniadeldesktop is offline erniadeldesktop
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
 

The Following 3 Users Say Thank You to erniadeldesktop For This Useful Post:
dwaradzyn is offline dwaradzyn
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:
shadowjk is offline shadowjk
2010-07-29 , 19:11
Posts: 1,258 | Thanked: 672 times | Joined on Mar 2009
#30
Originally Posted by DrWilken View Post
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
and

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.
Sound familiar from the "N900 stutters" threads?

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:
Reply
Page 3 of 31 12 3 4513 Last »

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 00:21.

Contact Us - Home - Archive - Top