IRC channel logs

<damo22>youpi: i think the cpus are sleeping a lot in cpu_pause() and the load on the host does not go up

<damo22>is it possible that the TLB shootdown code delays a lot if the whole cpu_using set is not ready for IPI sending?

<youpi>damo22: see ast_check()

<youpi>it tells the processor to do something

<youpi>such as a context switch to get a thread out of its processor because it's not supposed to run there

<youpi>« IRR 48 seems to be always set on »

<youpi>what is IRR 48 ?

<youpi>« what happens if a 251 interrupt happens from inside a clock interrupt? »

<youpi>interrupt nesting is supposed to just work fine

<youpi>« not being ready for IPI sending » is not supposed to happend often

<youpi>anyway that's a hypothesis you can check by printing stuff

<damo22>ast check is not inplemented for sp

<damo22>cause_ast_check is {}

<damo22>maybe that is why

<damo22>do i create a new interrupt vector for remote ast?

<damo22>or how would i pass a param to an interrupt handler?

<youpi>ast is not used much, do you actually see it used ?

<youpi>before investigating time in implementing / optimizing things, check whether it's actually useful to do it ;)

<youpi>ok it seems it's being used in task_suspend and alike, since they need to stop the task if it's running on another cpu

<damo22>i did printf("A") in cause_ast_check() and i see none

<youpi>you can probably add another interrupt line along CALL_SINGLE_FUNCTION_BASE

<youpi>oh, really? so it's not your problem at stake

<youpi>but we'll probably need to fix it sooner or later, since we need to be able to unschedule threads

<damo22>i did printf("T") in the tight loop waiting for signal_cpus to finish and theres only a few calls every second

<youpi>then that's not your problem at stake either :)

<damo22>where else could the cpu be busy

<damo22>in the scheduler?

<youpi>as I mentioned earlier, a backtrace in kdb would tell you

<damo22>the trace only tells for the current cpu, i will look in the manual to switch cpus

<damo22>cant find it

<youpi>damo22: alternatively, you can debug from a gdb attached to qemu

<youpi>possibly you can trace explicitly the thread that is running on the other cpu

2023-08-07.log