Re: BFS for the power kernel
 

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:
So changing to noop scheduler (BFS isn't there by default) can be done using:
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... ;)

Re: BFS for the power kernel
 

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...

Re: BFS for the power kernel
 

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"

That's why I wrote NEVERMIND... ;)

Re: BFS for the power kernel
 

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.

Re: BFS for the power kernel
 

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

It's worth a try... ;)

Re: BFS for the power kernel
 

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..

Re: BFS for the power kernel
 

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... :)

Re: BFS for the power kernel
 

I just leave this here for who is thinking wat?
don't mind me
http://ck.kolivas.org/patches/bfs/sched-BFS.txt

Re: BFS for the power kernel
 

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.

Re: BFS for the power kernel
 

Intrestng stuff, but the most crucial:

and

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 :)