IRC channel logs

<gnucode>se1 I am running OpenBSD on a Dell Optiplex...I forget which version...7010 or 8010 maybe.

<gnucode>sorry wrong channel

<damo22>i am convinced the problem is with the scheduler, after last night's bug fixing session

<damo22>youpi: do you have a recommended algorithm to rewrite the scheduler?

<damo22>i would rather not roll my own

<youpi>rewrite?

<youpi>why rewrite?

<damo22>its broken and poorly documented

<youpi>"broken" how?

<damo22>we possibly need something simpler

<youpi>again, before trying to fix a problem, make sure to pinpoint and understand the problem

<youpi>it's already quite simple

<damo22>what is the (5/8)^n thing for?

<youpi>where?

<damo22>recompute priorities

<youpi>priorities, you don't need to care about them

<youpi>that's not what will be making booting slow

<youpi>during boot you have threads that are either blocked or not

<youpi>but priorities won't make much of a difference

<youpi>priorities will just change the order in the run queues

<youpi>but that's not what will make boot slower/faster

<damo22>something is not quite right in the scheduler, it must be running the idle threads too often

<youpi>it has no reason to run the idle threads when there are non-idle threads to be run

<youpi>and it's not priorities that will change that

<youpi>*and*

<youpi>we *don't* have issues in UP

<damo22>if the cpus were fully utilized, the load on the host would be smp X00%

<youpi>so it's terribly little probable that it's the issue

<youpi>however, the IPI questions are indeed a new thing with SMP

<youpi>during boot, it's expected that cpu is not 100%

<youpi>since booting is waiting for e.g. disk reads etc.

<damo22>ok

<youpi>concerning the hang you have during the boot, I wouldn't be surprised that it'd be just a hang

<youpi>such as a race in whatever piece of the hurd

<youpi>we were used to have threads compete with each other in ext2fs for instance

<youpi>but we were not getting smp races

<damo22>doesnt it depend on how the priorities are taken into account when scheduling? what if the priorities of threads that need to run now are set too low, they will not be chosen to run even though they are urgent

<youpi>having threads interrupt every clock tick (10ms) is really not much compared to having threads run *at the same time*

<youpi>even if a thread has a *terribly* low priority, it will be scheduled if there is no other thread to run

<damo22>ok

<youpi>the idle thread gets the cpu really only when there is nothing to run, whatever their priority

<damo22>are you sure the code implements that correctly?

<youpi>otherwise UP wouldn't boot nicely

<damo22>no, there is #ifdefs for NCPUS > !

<damo22>for the scheduler

<damo22>its a different scheduler isnt it for non-UP case?

<youpi>there are not many places with NCPUS > 1

<youpi>and they are not dealing with priorities etc.

<damo22>thread_setrun is swapped out for simpler_thread_setrun or something?

<youpi>concerning races in ext2fs etc., when the SMP work began, I advised to bind all processes on cpu0, for a start

<youpi>to avoid such races, precisely

<youpi>evc_signal isn't actually used

<damo22>oh ok

<damo22>kern/eventcount.c: * The scheduler is too messy for my old little brain

<youpi>yes, that's the usual way of calling "code that I didn't write"

<damo22>how do i bind processes on cpu0

<damo22>do i do that in userspace or in gnumach at compile time

<youpi>it'll be simpler to just do that in gnumach

<youpi>in the init func

<youpi>when starting bootstrap

<youpi>thread_bind(current_thread(), master_processor);

<damo22>so is this because some of our programs are not smp safe?

<youpi>it's very probable that we have such kind of issues

<youpi>so better rule them out for a start

<damo22>ok

<youpi>ah it seems that the binding isn't inherited between threads

<youpi>you can add that in thread_create

<youpi>by just copying over bound_processor into the new thread

<damo22>where in starting bootstrap

<damo22>"* Start the bootstrap thread" ?

<youpi>boottsrap_create

<youpi>bootstrap_exec_compat is only a special case

<damo22>ah parent_task must be TASK_NULL for gnumach

IRC channel logs

2023-08-11.log