IRC channel logs

<damo22>youpi: seems like BSP keeps getting put on the end of the run queue and hardly ever runs the bound threads

<damo22>and nothing else runs

<damo22>i think the APs are in idle and have nothing to run because everything is bound to BSP

<damo22>what if the scheduler is just swapping between idle threads

<damo22>ie dispatching cpus onto their idle thread

<damo22>hmm i put an assert in thread_setrun, its never called with th = idle thread

<damo22>youpi: regarding "x86_64: fix NCPUS > 1 build of CX() macro" i thought %eax is the cpu number (8 bits), wont it break if you only set %eax with the cpu number but offset the cpu by the full register width for the cpu number?

<damo22>dont we need to xor %rax, %rax before setting the lower part of the register with the cpu number?

<damo22>i mean, if youre going to use the full %rax to refer to the cpu number

<youpi>damo22: on 64bit, 32bit instructions clear the higher part of the register

<damo22>really? ok

<youpi>damo22: I'm not surprised that the idle thread never calls thread_setrun, there is no reason for it to wake threads

<damo22>if i make bootstrap_create bind to cpu0, and threads to inherit the bound_processor from first thread of parent task, why am i getting hangs still

<damo22>maybe bootstrap_create is not the first thread of its task?

<youpi>it is not

<youpi>it creates other tasks

<damo22>as a hack should i just make all threads inherit master_processor

<damo22>as bound_processor

<damo22>inheriting it from the task doesnt work because i need to choose a thread to inherit from the task

<youpi>(sorry, I misunderstood your question, but the answer remains correct: it's not the first thread of the kernel task)

<youpi>you could as well just make all created threads bound to master_processor right from the thread_create function

<youpi>(though you don't want to bind the idle threads)

<damo22>except the idle threasd

<damo22>yea

<damo22>actually it doesnt matter because of:

<damo22> (void) thread_create(kernel_task, &th);

<damo22> thread_bind(th, cpu_to_processor(i));

<damo22>it binds it to the right processor before it runs it

<damo22>start pci-arbiter:

<damo22>hang

<damo22>ok i think i have all bound to bsp

<damo22>except idle threads

<damo22>it runs really slow

<damo22>100% load on the host

<damo22>[ 91.0200050] wd0 at atabus0 drive 0

<damo22>every time i interrupt it its in spl0(ast_taken , i386_astintr

<damo22>in theory it should not slow down if everything is bound to cpu0 right?

<damo22>it should just idle on APs and run as fast as smp1

<youpi>yes

<damo22>well its not

<youpi>(though idle thread trying to schedule something can take some contention on the scheduler structures, but that's supposed to happen only at tick time, so not often)

<damo22>kern/sched_prim:1739 myprocessor->state = PROCESSOR_RUNNING; shouldnt that be PROCESSOR_DISPATCHING ?

<damo22>why do we set it running again if it wasnt dispatched?

<damo22>no_dispatch_count = 0 so it doesnt really matter

<damo22> * NOTE: For fixed priority threads, first_quantum indicates

<damo22> * whether context switch at same priority is ok. For timeshareing

<damo22> * it indicates whether preempt is ok.

<damo22>so there is a chance if two threads have the same priority, it will not allow a context switch

<youpi>yes, sure

<youpi>that's time sharing

<damo22>first_quantum is a boolean that gets set

<damo22>it can block context switches?

<youpi>yes, but that's not a problem

<youpi>threads don't eat cpu time just for fancy

<youpi>so if they are ready to run, it's good to run them

<damo22>it seems to be spending a lot of time in i386_astintr

<youpi>idle threads are the only exception

<damo22>every time i break it mentions that

<youpi>is it interrupting an idle thread?

<youpi>or a non-idle thread?

<damo22>idk

<damo22>it interupted a non-idle thread

<damo22>db{0}> show thread

<damo22>task 2(f51d7cb0): thread 0(f51c8ac8) R....F

<damo22>db{0}> trace

<damo22>spl0(ast_taken(f51c8ac8,f51c8160,0,c100a59d,f51d4240)+0x32

<damo22>i386_astintr(f51d4240,c1015100,f51c7fe4,0,0)+0x20

<damo22>task 2 is acpi

<youpi>in that case it's a bit surprising, it shouldn't need an ast

<damo22>i think ddb always interrupts at a clock interrup

<damo22>kdb*

<damo22>or the clock interrupt is not being acked

<damo22>is that possible?

<damo22>something fishy is going on because every time i enter kdb, the clock interrupt is simultaneously registered as IRR = 48 in (qemu)

<damo22>info lapic

<damo22>it seems to do an i386_astintr after returning from every system call

<youpi>perhaps need_ast doesn't properly get cleared

<damo22>return_from_trap recursively checks for asts

<damo22>is it normal that every time i interrupt kdb, the backtrace starts with alltraps() at the base

<damo22>is that an exception?

<youpi>what do you mean "interrupt kdb" ?

<damo22>ctrl-alt-d

<damo22>enter kdb*

<youpi>entering kdb is handled within the keyboard interrupt handler

<youpi>so that's expected, yes :)

<damo22>ok

<damo22>i dont know what im looking for anymore

<damo22>(gdb) bt

<damo22>#0 0xc100b27f in apic_get_current_cpu () at ../i386/i386/apic.c:191

<damo22>#1 0xc1032d5b in cpu_number () at ../i386/i386/cpu_number.c:28

<damo22>#2 0xc1015311 in thread_invoke (old_thread=0xf51c8970, continuation=0xc100a604 <thread_exception_return>, new_thread=0xc1507978) at ../kern/sched_prim.c:655

<damo22>#3 0xc1015b6a in thread_block (continuation=0xc100a604 <thread_exception_return>) at ../kern/sched_prim.c:873

<damo22>#4 0xc100d011 in ast_taken () at ../kern/ast.c:111

<damo22>#5 0xc10364b0 in i386_astintr () at ../i386/i386/trap.c:613

<damo22>#6 0xc100a59d in _return_from_trap () at ../i386/i386/locore.S:510

<damo22>that is without entering kdb

<youpi>gdb probably doesn't know how to unwind from _return_from_trap

<youpi>kdb does know

IRC channel logs

2023-08-12.log