Announcing a resync and update of BFS for linux-3.19
BFS by itself:
-ck branded linux-3.19-ck1 patches:
Apart from a resync with mainline and merging of the pending patches that were around for BFS460, there are no new changes. Apologies if I've been unable to address any new issues posted here - as per usual lack of time is the reason. There are some pending changes to the scheduler for mainline (as pointed out by kernelOfTruth here: link) but they're not finalised so I won't be delaying this release to wait for them.
Thank you very much for the update, Con! :-)ReplyDelete
I hope, you(r) contributors, Alfred Chen, kerneloftruth and post-factum will catch it up soon.
Need to say, the rest of 3.19.y-gc tree (omitted his BFS port) from Alfred doesn't patch well with BFS-461 anymore. I for myself can't figure it out.
Please honor, that they all did great jobs in providing also additional preliminary patches for BFS/ CK in the meantime.
kerneloftruth's last proposed patch for the "pending scheduler changes" together with his late addon do work well on here, when applied to 3.19.0 + 3.19.y-gc (Alfred's BFS 460 port) patches + TuxOnIce + BFQ.
Combined preliminary kerneloftruth's "pending scheduler changes" for BFS patch:ReplyDelete
@ kernelOfTruth / Alfred ChenReplyDelete
sorry for my (google) english....
i noticed that
"sched: Fix lost reschedule in __cond_resched()"
has been renamed and another patch (loop) came to:
[1/2] sched: Fix missing preemption check in cond_resched()
[2/2] sched: Pull resched loop to __schedule() callers
Both patches are in Jacob Shin´s tip-bot:
I don´t know, but is it probably/possible, that these patches belong together???
Also, the following patch could be interesting:
sched: Fix preempt_schedule_common() triggering tracing recursion
(was [LKP,sched] BUG: kernel boot hang https://patchwork.kernel.org/patch/5830291)
thx to all
thanks for listing those !Delete
Alfred & Con are clearly the experts here,
I merely help out where I can as my knowledge of the internals or how things work is pretty superficial :)
My first test for BFS 461 run well last night. I will see what need to be updated in -gc branch and update it next week.ReplyDelete
For the incoming pending patches for schedulers, I agreed that we should wait till they are finalized. At the meantime, we can investigate __schedule() in BFS, it was introduce in 460 but reverted in 461.
I just booted up a kernel with your https://bitbucket.org/alfredchen/linux-gc/branch/linux-3.19.y-new branch integrated
and it constantly shows the following kind of errors:
Looks like I have to disable that config option for now :D
Many thanks for your extensive work !Delete
the following WARNING, kernel/workqueue.c: process_one_work
error message came up:
The strange thing is that the related upstream fix already is applied to BFS
Line 1958 is the last one of:
* context_switch - switch to the new MM and the new thread's register state.
static inline struct rq *
context_switch(struct rq *rq, struct task_struct *prev,
struct task_struct *next)
I used -new branch to sync up git tree when I code remotely. The last 4 commits on it is not well tested. So... *FORGET ABOUT IT* please.
BTW, Alfred Chen has rebuilt his -gc branch yesterday.Delete
My 3.19.2 with TOI and BFQ and Alfred's own updated patches, based on BFS 461, is running well on here.
Someone else wanting to test reads here, first:
and gets it here:
Best regards for all of you,
alright, just updated to your new -gc
thanks for letting me know =)
Thank you very much. Keep going :)ReplyDelete
Hi, is there a solution for single core, single thread, 32 bit pentium m CPU?ReplyDelete
debug preemptible kernel config is not enabled.
3.17 with BFS worked great, 3.18 and 3.19 does not boot at all without any message. Thank you.
I can confirm that the workaround described by jwh7 (SMP=y) does work for my single core, 32bit Pentium M processor.
Thanks for the hint. Using now the Zen 3.19.1 kernel.
And thanks Con for your work.
I had been having this issue as well; I had a hunch it was related to SMP in the kernel config, and was right. This is probably obvious to some, but I'll pat myself on the back anyway. :-P Running on 3.19.0-ck1 now; I set:ReplyDelete
$ zcat /proc/config.gz|grep SMP
# CONFIG_X86_BIGSMP is not set
I previously had the "Kernel panic - not syncing: Attempted to kill the idle task!" in 3.18, and 3.19 had another message when i tried disabling all the SMP, HT, AMD64 config options. Until I re-enabled SMP.
ck, Is this expected, and what other kernel options are 'required'? Thanks! -jwh
No it's not expected, it's clearly a bug as it should be possible to build a uniprocessor config. Using SMP as a config option will do as a workaround till I get around to finding out why and fixing it, thanks.Delete
I came across this; may well be deprecated and/or irrelevant, but in case its any help:Delete
I should also note that my Arch AUR linux-ck package build make config automatically enabled HT when I enabled SMP:Delete
...so its possible that the root cause is related to that and not just the SMP option(s).
[PATCHv2] mm/slub: fix lockups on PREEMPT && !SMP kernels
Just FYI I've hit this problem on x86. I think I used gcc 4.7 and 4.8, and
maybe also 4.6 earlier.
Here's the diff in asm after applying the fix:
240a: 0f 85 ce 00 00 00 jne 24de
2410: 89 75 f0 mov %esi,-0x10(%ebp)
2413: 8b 07 mov (%edi),%eax
- 2415: 8b 50 04 mov 0x4(%eax),%edx
- 2418: 8b 48 04 mov 0x4(%eax),%ecx
- 241b: 39 d1 cmp %edx,%ecx
- 241d: 75 f9 jne 2418
+ 2415: 8b 48 04 mov 0x4(%eax),%ecx
+ 2418: 8b 50 04 mov 0x4(%eax),%edx
+ 241b: 39 ca cmp %ecx,%edx
+ 241d: 75 f6 jne 2415
241f: 8b 4d f0 mov -0x10(%ebp),%ecx
2422: 39 48 08 cmp %ecx,0x8(%eax)
2425: 0f 85 9a 00 00 00 jne 24c5
As 3.19+ is broken now, this should go into stable.
Not sure if this applied to my early panic in cpu_startup_entry when running -ck built as uniprocesser; I saw that this patch is in linux 4.0, but I still get the panic.Delete
Just upload my linux4.0 syncup patch for BFS0461 at https://bitbucket.org/alfredchen/linux-gc/downloads/bfs0461_linux4.0_syncup.patchReplyDelete
Please be noticed that extract __schedule() and sched_submit_work() from schedule() used to cause some issues when ck release similar changes for BFS in 3.18 release, then it is reverted in 0460 for 3.19. Hopefully these are fixed in upstream kernel changes.
This sync-up patch effectively incorporates the changes to cfs into BFS, that kernelOfTruth had pointed to already some weeks earlier. Ported parts of this patch already have been working very well on here with 3.19.2..3 for many weeks now. The newly added chunks by Alfred (@3.19.4 applied if needed or not) don't show any issues, so far.Delete
@CK: Could be a bit too trivial for you to publish your new BFS/CK patchset. ;-)