Another day, another BFS test release. This one builds on the ideas in the 0.371-test3 patch I posted about since they're proving very positive. No April fools here. This looks like it's kicking arse.
Apply to a BFS 0.363 patched kernel such as 2.6.38-ck1:
Changelog from the patch:
Add a "sticky" flag for one CPU bound task per runqueue which is used to flag
the last cache warm task per CPU. Use this flag to softly affine the task to
the CPU by not allowing it to move to another CPU when a scaling CPU frequency
governor is in use. This significantly improves throughput at lower loads by
allowing tasks to cluster on CPUs, thereby allowing the scaling governor to
speed up only that CPU. This should aslo save power. Use the sticky flag to
determine cache distance in earliest_deadline_task task and abolish the
cache_distance function entirely. This is proven as, if not more, effective.
Add helpers to the 3 scaling governors to tell the scheduler when a CPU is
Replace the frequent use of num_online_cpus() with a grq.noc variable that
is only updated when the number of online cpus changes.
Simplify resched_best_idle by removing the open coded for_each_cpu_mask as
it was not of proven benefit.
Remove warnings in try_to_wakeup_local that are harmless or never hit.
Clear the cpuidle_map bit only when edt doesn't return the idle task.
Abolish the scaled rr_interval by number of CPUs and now just use a fixed
nominal 6ms everywhere. The improved cache warmth of the sticky flag makes
this unnecessary and allows us to lower overall latencies on SMP by doing so.
Please test this one thoroughly. It's very stable and now heavily tested, but I won't announce any new "release" till it's been tested for maybe 5 days or more. It appears better in all workloads and with and without cpu frequency governors. Again, only SMP will benefit from this patch, but it should change behaviour in all SMP now, not just with ondemand. However, the scaling governors should show the most improvement.
The best example (with ondemand) was a single threaded cpu bound workload that took 126 seconds to complete on an i7 2 core/4 thread machine that now takes 91.5 seconds. The 2 threaded workload dropped from 66 seconds to 51.5 seconds. Note that this more or less addresses a regression in BFS behaviour with cpu frequency scaling on SMP, but it's also been an opportunity to improve behaviour elsewhere.
I can't restore the system after hibernating it correctly. After a while the system hangs and CAPSLOCK starts blinkingReplyDelete
Thanks. Is this different to BFS363 or vanilla 2.6.38?ReplyDelete
I have that error after hibernating. But only with kernels 18.104.22.168 and 22.214.171.124. 126.96.36.199 works fine.ReplyDelete
I've just tried your patches (ck1 + bfs363-372-test.patch) with 2.6.38 (no .1 nor .2) and I can resume normallyReplyDelete
With newest stable-queue, like this:
well...It's really soon to see this post...after I pack the last one this morning. XD This is the opensuse repositoryReplyDelete
The packages are kernel-ck100hz, kernel-ck1000hz for server and desktop. Everything seems be OK. I didn't get any problem for the last 12hrs. The OpenSUSE users may give it a try...
Thanks for feedback. I don't think the hibernate issue has anything to do with this patch since it is kernel version related. Sorry I posted a new patch so soon after the other test patch, but I wasn't sure when I'd be able to "finish" the last test patch and managed to do so sooner than expected. I'm hoping not to have to do anything to this current version since it appears to do everything I need quite well.ReplyDelete
Here, read this link about suspend/resume issues with 188.8.131.52 :ReplyDelete
Hi, in another post you wrote you're using kde + nvidia, so I'd like to know if you're experiencing the same problem as me: with compositing active the whole desktop experience is slowed down progressively, up to a point where typing a character requires half a second for it to appear. I noticed this with vanilla and -ck, but -ck seems to make the degradation a bit faster. Without compositing -ck is multiple times more reactive than vanilla.ReplyDelete
Yes that's right. No one admits fault there, neither nvidia nor kde, but it's clear that it's a problem when compositing+kde+nvidia are used on kde4. However I found the problem is much rarer on kde4.6 since upgrading to that. Usually flicking to another TTY/console and then back to my desktop fixes it.ReplyDelete
I have kde-4.6 with Composite-kwin, but most modules of win-effects disabled.ReplyDelete
I do run my core2 Gentoo 64bit system since my first post today without problems!
@Alberto, try to change "Desktop Effect -> Advance -> Scale Method" to Smooth.ReplyDelete
@Alberto, try it: http://techbase.kde.org/User:Lemma/KDE4-NVIDIAReplyDelete
FYI Ubuntu users: I have copied a patched kernel into my ppa.ReplyDelete
I am currently running, and I am getting better scores on the kraken benchmark for all frequency governors. ondemand is still allot slower for me (18s vs 13s for conservative).
Running like a champ here.ReplyDelete
cool ur champReplyDelete
Counter Strike Hacks