IRC channel 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

<solid_black>hello!

<damo22>hey

<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>break*

<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.

IRC channel logs

2023-08-14.log