IRC channel logs

<damo22>youpi: have installed those

<damo22>youpi: should i apt upgrade?

<damo22>youpi: do you have any ideas what could be missing if we shouldnt merge "kern/sched_prim: Simplify by not dispatching to idle cpu directly"

<damo22>on master, smp hangs in rumpdisk somewhere

<damo22>otherwise if it doesnt hang it is very slow

<damo22>i just applied that experimental patch and it booted to a shell with smp 4

<damo22>and again with smp 7

<damo22>then hung during boot with smp 6

<damo22>youpi: i think the problem is a combination of thread_setrun and idle_thread_continue, when a thread is dispatched direct to an idle processor, thread_setrun just returns, but idle_thread_continue is sitting in HLT=1 so never detects the processor->next_thread has changed until some time later, so its a slowdown

<damo22>i think this is in the case when processor == current_processor()

<damo22>how do i wake up the current_processor?

<damo22>or can i just execute the thread directly?

<youpi>if processor == current_procesorr(), you have nothing to do

<youpi>making hypotheses is nice, but put printfs etc. to actually observe what is actually happening

<youpi>otherwise you'll be messing with the code in all kinds of directions without converging on actually fixing things

<damo22>nothing to do? in that case shouldnt the processor just run the new thread?

<youpi>yes, isn't that what the scheduler does?

<damo22>no it returns

<youpi>I mean: you jus tdon't have to IPI

<youpi>I mean: "wake up the current_processor" is meaningless

<youpi>it's already woken up

<damo22>i mean the else case of this:

<damo22> if (processor != current_processor())

<damo22> cause_ast_check(processor);

<damo22> else {

<damo22> thread_t mythread = th;

<damo22> processor->first_quantum = TRUE;

<damo22> processor->next_thread = THREAD_NULL;

<damo22> processor->state = PROCESSOR_RUNNING;

<damo22> thread_run(idle_thread_continue, mythread);

<damo22> }

<youpi>you shouldn't need to cause an ast check, you're already in the scheduler code

<youpi>and again, things work just fine in UP

<damo22>we already cause ast check when not on current processor

<damo22>i added that else case

<youpi>sorry, misread the code

<youpi>but then my point is still: you shouldn't need anything about the curent processor, since in UP (where we're *always* the current pr'ocessor) we don't have any oissue

<damo22>true but you are concerned about loss of parallelism

<damo22>this only affects smp

<youpi>yes, but that's not about when we're current_processor

<youpi>but when there's anotheri processor that is idle

<youpi>and then we want to send an ipi

<youpi>and *that* is what I guess is currently bogus

<youpi>something like: we're just keeping sending ipis, overflowing the other

<damo22>i will prove this is not happening with prints

<youpi>or we don't actualyl succeed doing the ipi, and thus the thread doesn't wake up until the tick period

<damo22>ok

<youpi>or whatever other scenario like that

<youpi>but I really doubt it's a problem of "how do i wake up the current_processor?"

<youpi>since in UP we don't have any issue

<damo22>i tangled myself, i meant the problem is "how do we reschedule a chosen thread onto current processor"

<youpi>I understood that

<youpi>but my ponit is still the same

<youpi>UP would need to do that exactly

<youpi>and it works in UP

<damo22>ok

<youpi>so it does work

<damo22>it may be working badly

<youpi>why?

<youpi>I mean

<youpi>leave apart the other processor

<youpi>let's think like the scheduler doesn't actuall see them

<youpi>that's exactly like UP

<youpi>it does work

<youpi>why would it be different

<youpi>(maybe I'm wrong there, but then that pinpoints the pieces of code marked NCPUS>1, but then you can inspec that)

<youpi>the most probable issue is about the *other* processors

<youpi>since that's what is really new with SMP

<damo22>is it possible for current_processor() to be idle?

<damo22>if it is executing scheduler code

<youpi>what do you mean by "to be idle" ?

<youpi>(again, that'd be the same problem with UP if it was a problem)

<damo22>by processor->state = PROCESSOR_IDLE

<youpi>wouldn't that be possible to happen in UP?

<damo22>yes looks like it

<damo22>if (default_pset.idle_count > 0) { exists in UP

<youpi>so if that was a problem, we'd have the issue in UP

<youpi>we don't

<youpi>so it's very little probable that we'd have it in SMP

<damo22>but i dont know if that code path ever runs in UP

<youpi>then printf it

<damo22>ok it is

<damo22>its a very frequent code path

<solid_black>hello!

<damo22>youpi: remote asts seem to be working

<damo22>they are about the same frequency as ast_on() in UP

<azert>Hi all, on top of the possible ipi issue, that I guess can be easily disproved, could it be that the code damo22 commented out is just very slow?

<youpi>it's not

<damo22>it should improve performance with the code remaining in there

<damo22>but it does the opposite

<azert>The question is if it is broken or just slow, youpi thinks it is broken

<damo22>all it does is schedule a thread that is ready to run onto an already known idle processor

<azert>Ok but who does that? A random processor?

<damo22>as long as the cpu is woken up to run it, it should be faster than letting it wait for the run queue

<damo22>i dont know which cpu runs the scheduler

<azert>Every cpu is basically losing time to schedule stuff on other CPUs? Or just one?

<damo22>they are all in HLT=1 state until a periodic interrupt wakes them

<damo22>or they are running

<damo22>i think the scheduler gets triggered like any other thread

<damo22>so it consumes a small runtime on potentially each processor

<youpi>the scheduler is not a thing that runs

<youpi>it's a bunch of functions that all threads run

<youpi>when they block, or on clock interrupt

<youpi>so all cpus run it whenever it makes sense to

<azert>Why it doesn’t make just sense that every cpu gets the thread for itself from the queue then?

<damo22>sched_tick = 0;

<damo22> * sched_thread: scheduler thread

<damo22>oh that gets woken like another thread to recompute priorities

<azert>I think that in the past the idle thread was the scheduler thread, now things changed

<damo22>azert: my limited understanding is that the cpu tries to get the next_thread while in idle thread but goes to sleep until an interrupt

<damo22>if it cant run something immediately, it halts

<azert>That’s good for powersavinf

<damo22>yeah but i dont understand which instruction is executed next when it wakes up

<damo22>ie, does it loop around and check for a next_thread again

<azert>No it’s the interrupt code

<damo22>i mean when it irets

<azert>I guess it shouldn’t do that otherwise it will go back to sleep

<azert>Or the next instruction?

<damo22>yeah i dont know

<azert>Probably it loops around like you said

<damo22>so if it loops around, i guess it will check the condition in the while loop again

<damo22>and break out if there is something to run

<damo22>so the only reason i can see why the code would fail to run correctly, is if the idle processor does not receive the IPI so stays asleep until next clock interurpt

<damo22>but we cause_ast_check() on the idle cpu

<azert>Hope you are right

<damo22>another thing i can try is remove the machine_idle() hlt call then it should consume more cycles, but not delay

<azert>What is the value of th->last_processor if the thread was never scheduled before?

<azert>Also maybe when choosing an idle processor, it should first check if current processor is idle and pick this in case

<azert>Just pointing two other possible breakages

<damo22>theres two cases, if the thread is bound to particular processor, or not

<damo22>it should not matter which idle cpu you put it on

<damo22>unless bound to one

<damo22>HW_FOOTPRINT is 0

<damo22>what is preempt check for?

<damo22>and how do you do a preempt check on SMP?

<damo22>is it always related to current_processor() ?>

<damo22>in the unbound case, we dont actually know which processor will run the thread, so we cant do a preemption check right?

<damo22>we just know its one out of the processor set

<damo22>ah we can check if current processor is in the pset, and then choose to alert the current processor if so

<damo22>which the code already does

<azert>Followed the conversation with you folks last week with Kent Overstreet, on youtube

<azert>I guess that was a lot of fun

<azert>reading about his work made me think of a provocative thought: these dudes at Microsoft or Google or IBM or whatever are all into deduplication, snapshotting and copy on write

<azert>What people really want, what they need, is in fact transparent duplication and distribution

<azert>It has been like that for three decades

<azert>Quite the opposite of what these people are designing for

<azert>You don’t want to know that some weird data deduplication saved you lots of space from the 30 copies of the os you are snappshotting. What you want to know is that your data is safe stored on 5 servers on three continents so you don’t need to worry buying a sixth one

<azert>Does the Hurd provides any advantages for that over Linux?

<azert>What’s even the point to keep free space? You want to use that to backup other people data

<Gooberpatrol_66>azert: distributed fs like tahoe-lafs, ipfs, gluster have this

<Gooberpatrol_66>these could become native-ish with a fixed fuse translator

<Gooberpatrol_66>even normal cow filesystems like btrfs/zfs/bcache have tools for sending snapshots between computers

<Gooberpatrol_66>i send all my snapshots to a different building for backups

<azert>Gooberpatrol_66: maybe we need a new global distributed fs based on gnunet, since anything you mention doesn’t provide the kind of privacy and freedoms that the gnu project sponsors

<azert>In gnunet files are immutable tough

<gnucode>azeem: gnunet is somewhat slow too...

<azert>gnucode: true, very true

<azert>I was thinking more like a fs where you keep files on your hard disk and it’s as fast as normal, but that also in the backgrounds it download files from peers and shares to them your free space as a backup.

<azert>At the same time, they do the same to you. Of course everything is stored encrypted and readable only by the owner

<azert>If you delete a file, it should also be deleted from everyone else by default, with an exponential decay limit like 1 months where you might have a chance to recover deleted files

<azert>You would have a way to know how many backup copies are around the network

<azert>Although it shouldn’t be guaranteed, in a sense that there should always be a probability of having zero backups. But the network should be built in a way that this probability is very low

<azert>And that you should be able to rebuild everything in case of hardware failure

<gnucode>azeem: rsync

<azert>I wasn’t clear enough: I’m talking about a communistic file system and a de facto a communistic bot net, that does stuff you don’t want to hear about behind your back for the common good. Similar to cloud providers but with totally different purposes

<azert>rsync don’t do that

<azeem>gnucode: you keep hitting the wrong nick

<gnucode>azeem: not sure what you mean

<azert>azert is not azeem

<gnucode>gotcha

IRC channel logs

2023-10-04.log