IRC channel logs


back to list of logs

<damo22>youpi: idle_thread_continue is never called ?!
<damo22>its only called at the beginning
<damo22>like once per cpu
<damo22>ah that makes sense because its a while (TRUE) loop
<damo22>but it doesnt seem to break when i put breakpoint inside the while loop
<damo22>after machine_idle() call in idle_thread_continue, cpu0 never reaches that codepath
<damo22>with all threads bound on cpu0
<damo22>(except the idle threads)
<youpi>damo22: see the thread_block semantic
<youpi>that's actually an escape from the while loop
<damo22>i cant see how the scheduler works if it never executes past machine_idle
<damo22>idle_thread_continue is mostly useless then
<damo22>for example, gdb never breaks on * Commmon case -- cpu dispatched.
<damo22>or before that if block
<damo22>how do i interrupt the cpu that is currently executing the scheduler code to make it dispatch a thread immediately?
<youpi>the ast_taken() call may be catching all the scheduling request
<youpi>that's because we have added the cause_ast
<youpi>in the old days one wouldn't use IPIs and just let "idle" cpus keep looping
<youpi>running sched code
<youpi>« how do i interrupt the cpu that is currently executing the scheduler code to make it dispatch a thread immediately? » ← ?? you don't need to do that
<youpi>if it's executing the scheduler code, it'll find a thread to execute
<youpi>so you can just leave the thread on a runq, and the scheduler will find it
<youpi>it's only when the cpu is stuck in the idle loop that you may want to give it a thread explicitly
<damo22>there are many codepaths, its confusing
<damo22>i thought the point of the cause_ast_check was because idle cpus were in HLT=1 and that causes an interrupt, but where do they execute after iret?
<damo22>do they continue just after the hlt instruction?
<damo22>and loop around
<youpi>they run the ast
<youpi>which can just preempt it for instance
<damo22> machine_idle(mycpu);
<damo22>#endif /* POWER_SAVE */
<damo22> } <---- does the iret jump here?
<damo22>if it does, that means the ast check code above within the while loop would not be executed because the *threadp would become non-NULL
<damo22>so the while loop would beak
<damo22>but im not seeing that in gdb
<damo22> if (!restart_needed)
<damo22> restart_needed = do_runq_scan(&master_processor->runq);
<damo22>why does the do_thread_scan only check master_processor's run queue?
<dormito>I could not find a list of supported arch's on hurd's website, but by various documetion wording, and a quick glance at gnu-mach's source, it seems only i[3456]86 and x86_64 are supported. Is this (if correct) an intentional limitation of scope, or just not had other arch support written?
<damo22>dormito: no time to implement other arches, when i386 is still not finished
<solid_black>dormito: i386 is working and supported, x86_64 is up-and-coming and experimental (somewhat working), nothing else has been implemented yet
<solid_black>but it's not an intentional limitation
<dormito>ah, nice, thanks.