As seen on this blog previously, a bug showed up in 3.4-ck2/BFS 423 to do with unplugged I/O management that would lead to severe stalls/hangs. I'm releasing BFS 424 officially and upgrading 3.4-ck2 to 3.4-ck3, incorporating just this one change.
BFS 424:
3.4-sched-bfs-424.patch
3.4-ck3:
3.4-ck3/
Others on -ck2 can simply apply the incremental patch to be up to date.
3.4bfs423-424.patch
Enjoy!
お楽しみください
Seems like this patch made BFS stable again. Passed 28h of uptime now without any problems.
ReplyDeleteKernel 3.4.4 from openSUSE, BFS test increment to 0.424 + mm-drop_swap_cache_aggressively.patch, BFQ. And WITH CONFIG_JUMP_LABEL = y now, of course. ;-) :-D
Very snappy experience now! Also I don't find the system to be slowing over this uptime. Thank you, Con, for your work and to find out the culprit!
Best regards,
Manuel
54h uptime, Manuel
DeleteSo I'm canceling this test at 78h of stable uptime.
DeleteThe most unresponsive application was firefox after 3 days running. After closing and restarting with the very same tabs it was snappy again.
I definitely need to unlearn to blame the CPU scheduler first when things get slow.
Manuel
It's been about two years since last I slapped your BFS on a kernel. It has come a long way. The responsiveness and stability of 424 is incredible. Thank you much for doing the hard work, you perennial underdog you. (-;
ReplyDeleteVery kind words, thank you! :-)
DeleteAlso with kernel 3.4.5 + BFS 0.424 and the mm-drop_swap_cache_aggressively.patch I'm more than glad! Seems like background load dropped a bit for me with this kernel release.
DeleteBest regards, Manuel
CK - can you build against 3.4.6 with BFS v0.424? I get errors on make modules:
ReplyDeleteCC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
kernel/built-in.o: In function `tick_nohz_stop_sched_tick.isra.9':
tick-sched.c:(.text+0x49d39): undefined reference to `calc_load_enter_idle'
kernel/built-in.o: In function `tick_nohz_idle_exit':
(.text+0x4a0b7): undefined reference to `calc_load_exit_idle'
make: *** [.tmp_vmlinux1] Error 1
Linux-3.4.6-bfs runs stable here. NO_HZ can save some 3percent energy using HZ_1000, but down to HZ_300 it is only a third of that. And it this NO_HZ full of bugs - see the fixes every now and then. Having a fine tuned config you should not feel any difference as a user using only 300 HZ. Did you once manual saved the times for running athletes at school: Measuerd any difference of 2 thousands of a second? Overall troughput should be better using only HZ_300.
DeleteThe ckN-patches should define more reasonable values:
---
# CONFIG_NO_HZ is not set
...
CONFIG_HZ_300=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=300
...
# RCU Subsystem
#
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_FANOUT=64
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_BOOST=y
CONFIG_RCU_BOOST_PRIO=14
CONFIG_RCU_BOOST_DELAY=440
---
Setting CONFIG_RCU_BOOST_PRIO higher results in a kernel task
rcun having -15 priority (minus plus one!?). This is a workaround for me having no more overflow of process times.
Putting CONFIG_RCU_BOOST_DELAY a ten percent down result in general lesser latency even when using the mainline CFScheduler.
Ralph Ulrich
Hmm, wait wait... Con says CONFIG_HZ_1000 is better for desktop use (responsivity), you say CONFIG_HZ_300 is better for troughput and one "should not feel any difference" using 300. Debian uses 250. Aptosid 1000. Now I'm confused...
DeleteActually I just wanted to emphasize direction graysky:
Deleteinstead enabling a buggy - not recommended - CONFIG_NO_HZ
if you need mobile energy saving do a slightly fine tuning to
RCU_BOOST
and reset CONFIG_HZ_1000 to 300
This saves 2third of the energy savings of CONFIG_NO_HZ
Ralph Ulrich
I have the same building issue too ;)
DeleteThanks for telling me how to cope it.
just an observation from my side. i am not sure if it is BFS or mainline, and why I didn't observe it previously with incremental patches, but yesterday I rebuilt 3.4.6 with patch-3.4-ck3 and i had a build issue on one of the machines. The laptop has CONFIG_NO_HZ for reasons of battery life, and i needed to comment out the following lines in include/linux/sched.h (from line 2028):
ReplyDelete//#ifdef CONFIG_NO_HZ
//void calc_load_enter_idle(void);
//void calc_load_exit_idle(void);
//#else
static inline void calc_load_enter_idle(void) { }
static inline void calc_load_exit_idle(void) { }
//#endif /* CONFIG_NO_HZ */
@graysky: This is related with an issue by Martinus below.
ReplyDelete@Martinus: This issue is introduced by the mainline patch-3.4.6. I circunvent this with the patch below. I guess that the same issue presumably will appear in linux 3.5 (already out!).
Fernando Auil
--- a/include/linux/sched.h 2012-07-23 19:40:10.000000000 -0300
+++ b/include/linux/sched.h 2012-07-23 19:56:51.000000000 -0300
@@ -2028,7 +2028,7 @@ static inline int set_cpus_allowed_ptr(s
}
#endif
-#ifdef CONFIG_NO_HZ
+#if defined(CONFIG_NO_HZ) && !defined(CONFIG_SCHED_BFS)
void calc_load_enter_idle(void);
void calc_load_exit_idle(void);
#else
Is there any progress on -ck/BFS for 3.5?
ReplyDeleteHi
ReplyDeleteWith new kernel 3.2.25 bug with BFS:
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
kernel/built-in.o: In function `tick_nohz_restart_sched_tick':
(.text+0x31241): undefined reference to `update_cpu_load_nohz'
make[3]: *** [.tmp_vmlinux1] Error 1
This error after remove this patch :
ReplyDelete--- a/include/linux/sched.h 2012-07-23 19:40:10.000000000 -0300
+++ b/include/linux/sched.h 2012-07-23 19:56:51.000000000 -0300
@@ -2028,7 +2028,7 @@ static inline int set_cpus_allowed_ptr(s
}
#endif
-#ifdef CONFIG_NO_HZ
+#if defined(CONFIG_NO_HZ) && !defined(CONFIG_SCHED_BFS)
void calc_load_enter_idle(void);
void calc_load_exit_idle(void);
#else
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
kernel/built-in.o: In function `tick_nohz_stop_sched_tick':
(.text+0x30fa2): undefined reference to `calc_load_enter_idle'
kernel/built-in.o: In function `tick_nohz_restart_sched_tick':
(.text+0x31241): undefined reference to `update_cpu_load_nohz'
kernel/built-in.o: In function `tick_nohz_restart_sched_tick':
(.text+0x31268): undefined reference to `calc_load_exit_idle'
make[3]: *** [.tmp_vmlinux1] Error 1
http://pastie.org/4386744
DeleteUntested but since bfs uses the old global load calculation I don't see why it wouldn't work unless I forgot something else. Basically just making it compile should be good enough since I'm fairly certain it doesn't use any of the new stuff although with something as complicated as the linux kernel shit sometimes happens.
Hi TheRyuu
DeletePatch is ok but apply only manual
after create patch fail and go to apply on kernel crash in second file tick-sched.c not ok to patch.
m.
This comment has been removed by the author.
ReplyDeleteHARPREET-SHARDA
ReplyDeleteI have to say your article inspires me to the most, it is so instructive to tell others how to understand that in such a special view.I will share your articles with my friends, i think they will like them just like me. What's more, can you update them more frequently? I am a fan of online games. rs gold , runescape gold
ReplyDeleteHey Con Kolivas, any chance of a android msm patch for bfs?
ReplyDeleteI was wondering if you had any interest in making bfs compatible with ARM
ReplyDeleteBFS for ARM SMP is currently broken and I would like to see it fixed, I believe it would be extremely beneficial to multi-core ARM devices.
I just don't have the time, sorry. I barely have enough time to maintain BFS as it is, and there's no sign that will change any time soon.
DeleteOk thanks. Not the answer I was hoping to hear but it is what it is. Maybe if you happen to get some free time you could try porting to arm, if not that cool was worth a try.
Deleteseems to be very stable and advanced build there, I am so proud for you and will continue using this kernel for many years to come, this is truly the finest one available, just like this website to buy rs gp, its just unparalleled
ReplyDelete