Re: BFS for the power kernel
 

Its an informative statement, perhaps stating the obvious, and apparently not what you'd like to hear.

Fact is, you are not kernel-power, so you should not be named kernel-power. Hence, this should be fixed, and you might have to conflict with them in your rules.

Same as for the other package, fcam-drivers. When I updated using APT it tried to overwrite your version. Not good.

You're also not compatible with multiboot, so you should conflict with them for now as well.

Anyone can apply some kernel patches and share the compiled packages, but good packages and incentive to install the package (in this case benchmarks) are the actual gems.

Personally, I believe updating to a newer kernel is the best way to go since CFS has gone through a lot of updates ever since 2.6.28. Until benchmarks, I see this as yet another of those BFS-is-great-but-im-not-proving-why threads. And, just because Android kids do it doesn't mean its justified.

Re: BFS for the power kernel
 

Well, even though your observations are probably correct (I don't use multiboot & fcam myself), you should know that installing this kind of packages can brick your device (see the big extra-devel warning; this package isn't even is extra-devel, so even more caution is advised). Nonetheless, it is good to point out these kind of errors, I'm sure that coreyoconnor appreciates it :)

I'm a big fan of the BFS scheduler. Unfortunately, I can't provide any benchmarks. I've tried installing latencytop, but when I tried to run it, it complained that CONFIG_LATENCYTOP is not enabled in the kernel configuration. This implies that it also isn't enabled in the standard kernel-power package, so both of these kernels should be recompiled if we want to benchmark with latencytop.

However, since BFS is designed for systems with just one/a few cpu threads and with desktop responsiveness in mind, my guess would be that it is actually better than the default scheduler. I can't back up this statement though, but hey, nobody's forced to use BFS ;)

Thank you for updating this package, I really appreciate the effort. If it wasn't for my C knowledge, I would certainly give it a try.

Keep up the good work!

-iDont

Re: BFS for the power kernel
 

You are delusional if you think Ingo Molnar and co give a damn to desktop performance. Improvement from BFS may be hard to quantify, but I have way more trust in Con Kolivas.

Also, as you do seem to like benchmark, you do realize that Con Kolivas is the only person that came up with something to benchmark desktop responsiveness (i.e. interbench)?

Re: BFS for the power kernel
 

He had to start caring after peer pressure, and from what I remember on Phoronix performance has improved thanks to work by people from Intel et al (IIRC Peter Zijlstra and Arjen v/d Ven; not sure). Guess why Intel cares? Hint: they're not going to use 2.6.28 on MeeGo/x86-32. We're on 2.6.35 now whereas the kernel we use on N900 is 2.6.28. Ofcourse, the difference between Linux kernel 2.6.35's CFS versus BFS compared to 2.6.28 CFS versus BFS is lower given CFS has been more polished ever since.

Given that I actually believe you do have a fair chance to be able to support your theories (that BFS for Linux kernel 2.6.28 can provide better performance than CFS for Linux kernel 2.6.28). Still no benchmarks from the fanboys though, and the way the packages interact with what is there is rather broken which boils down to "use this at your risk, but it really works". Sounds like LSD to me.

Re: BFS for the power kernel
 

Ah. Now that *is* helpful! I'll see if I can enable it in the kernel.

Re: BFS for the power kernel
 

lkml.org is currently not loading for me, but I recall that some of the low latency CFS patches where funded by Nokia. Which, to me, implies Nokia is certainly interested in low latency system response regardless of what Ingo wants :-)

Here's the google cached lkml post

Another thing to note is that BFS does not support cgroups. Which, as I understand it, Maemo uses to set the priority of processes. This is, IMO, a very useful feature.

Re: BFS for the power kernel
 

Well, cgroups is exactly the kind of thing that Ingo and co like. It was designed for multi-user system, not desktop. There was actually a thread that talks about disabling cgroups to help N900 performance:

http://talk.maemo.org/showthread.php?p=568594

Looking at N900's overly complicated cgroups setup (/usr/share/policy/etc/current/syspart.conf), I can't help but wonder if cgroups is the cause of all the responsiveness problems.

sched_rr, sched_iso, and sched_batch are much simpler to deal with.

Re: BFS for the power kernel
 

I ran the command, (step 4) and it doesn't work. I get an error saying "dpkg error processing *bfs0_armel.deb (--install):
: cannot acess archive : No such file or directory
Errors were encoutered while processing: *bfs_armel.deb"

Can I get some help ): ?

Re: BFS for the power kernel
 

Hm. Did you extract the archive using the command line tar program? Or did you extract it using a GUI program? The extracted archives might not be in the directory you are running dpkg.

What is the result of executing this command:

Re: BFS for the power kernel
 

Sorry, I'm an n900 noob, I thought the dpkg command was the extracting command? And I'm also sorry for late reply, been busy. I'll try it right now.

EDIT: Doesn't work and I'm guessing I didn't extract it right. Could I get the Terminal command line on how to extract it please?