IRC channel logs


back to list of 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
<damo22>if that
<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
<azeem>GNU/Hurd somehow made top spot at Hacker News:
<azeem>(it's about this article: