IRC channel logs


back to list of 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>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>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
<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>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>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>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>enter kdb*
<youpi>entering kdb is handled within the keyboard interrupt handler
<youpi>so that's expected, yes :)
<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