IRC channel logs

<damo22>sneek: later tell almuhs yes, i have seen this error on all my intel thinkpads, but it is an improvement as before it did not probe the AHCI controller at all

<sneek>Okay.

<ZhaoM>morning, https://darnassus.sceen.net/~hurd-web/ is down

<youpi>ZhaoM: I have updated the bootstrap wiki page

<ZhaoM>youpi: just saw it. Thanks :)

<damo22>solid_black: hi

<solid_black>hi!

<sneek>Welcome back solid_black, you have 1 message!

<sneek>solid_black, youpi says: thinking about gnumach's out-of memory management, it used to be able to write out to swap by itself without userland interaction. This is not the case any more. Possibly that changes a few things

<solid_black>youpi: what do you mean write to swap without userland? paging out is always to a pager

<youpi>doesn't it have a default pager by itself?

<youpi>but still if it's the userland default pager, that has to use rumpdisk, which might have to allocate memory to be able to write out

<solid_black>the default pager is still a userland task, yes

<solid_black>and yes it might have to allocate

<solid_black>and there are 3 things we should do about it:

<solid_black>1. try to page things out more eagerly while we're not yet very low on memory; this is why I'm interested in making writing out dirty pages work better

<youpi>1. is good for optimization, but won't solve the problem of a fast writer

<solid_black>2. try to make the swap path avoid allocations (e.g. I can see it currently has to allocate when things are not page-aligned, so let's make sure that they are page-aligned in practice)

<solid_black>3. the vm_privilege thing, so rumpdisk etc can still allocate even when everyone else cannot

<youpi>avoiding allocation will not always be possible, but it should be possible to make sure it can allocate by keeping sure gnumach has a reserved pool

<youpi>(so 3.)

<solid_black>yeah

<youpi>fixing 1. and 2. risks just hiding the problem that 3. will solve

<youpi>and thus making it harder to make sure it's fixed

<youpi>so better start with 3.

<solid_black>neither is a full fix, these are all approaches to making the issue less severe and likely

<solid_black>so is OOM

<youpi>OOM is a different thing

<youpi>if the *working* set indeed cannot fit the memory, we'd have to kill

<youpi>but when it's just about writing out paged stuff, we should be able to just make it work

<youpi>by throttling writes, if needs be

<solid_black>writes are already naturally throttled by the Mach port queue limit, as I was saying

<youpi>(I mean io_write, not memory writes, which are quite harder to throttle)

<solid_black>or at least that should work, we need to fix it if it doesn't

<youpi>no, they are not

<youpi>because ext2fs process them and marks as "needs write"

<solid_black>I meant page writeback / pageout

<youpi>ok, but then ext2fs also needs to throttle at some point

<youpi>otherwise a fast writer will still be able to fill its memory

<youpi>concerning darnassus, the hosting has /var full, richard needs to fix it before we can restart it

<solid_black>what's up with darnassus, I'm not up to date?

<youpi>it's currently completely off and I can't fix it myself

<solid_black>ah

<youpi>(it was a general message for everybody, not for the current discussion :) )

<solid_black>btw will there be / is there a similar x86_64-gnu server I could get an account on?

<damo22>im looking forward to having rumpnet working, i will be able to host a native hurd box on an AMD box

<youpi>there should be at some pont yes

<damo22>i used to have a vm running online

<damo22>but i was using it to test my changes to gnumach and i couldnt keep it online

<damo22>but when i have a network interface up with smp i can keep it online

<damo22>our current problem with smp + rumpdisk is that the disk devices fail to identify, something to do with multiple threads and interrupts

<damo22>its the problem almuhs reported, i have seen it on hardware

<youpi>darnassus is back

<damo22>\o/

<damo22>youpi: (08:32:44 PM) damo22: our current problem with smp + rumpdisk is that the disk devices fail to identify, something to do with multiple threads and interrupts

<youpi>is rumpdisk really multithread?

<damo22>not sure

<damo22>it is configured to use RUMP_NCPU=1

<damo22>maybe i should try 2

<youpi>that cannot help

<youpi>on the contrary

<damo22>but i recall the default is 2 and it used to break then

<youpi>it'll make things way more complex to check

<damo22>it used to behave exactly like this when it was 2

<damo22>on UP

<damo22>when i added the param to make it 1, it worked on UP

<damo22>maybe we should turn off the multithreading on the port server?

<damo22>see if anything changes

<youpi>that can help with stability yes

<youpi>but that won't help with performance, because iirc currently we are blocking

<youpi>i.e. making it single-thread will make i/o completely synchronized, waiting for one to finish before starting the next one

<youpi>thus preventing all pipelining and aggregation possibilities

<damo22>i tried that it did not help boot the disk

<damo22>IDENTIFY failed

<youpi>but the interrupts are received in their own thread anyway, aren't they?

<damo22>yes

<youpi>so you'll have multithreading anyway

<youpi>but is rumpdisk actually running on several cores?

<youpi>or pinned like all others on just one

<damo22>pinned

<youpi>ok so it's not really multithreading that would pose problem

<youpi>it's all sequential

<youpi>the disk irqs probably happen on core 0

<youpi>you can check that for a start

<youpi>and concerning identify, check what happens

<youpi>whether it's the content that is faulty, that it doesn't get the irq back, etc.

<youpi>it's useless to try and fail odd ways to make it work, there are so many of dumb things one could try

<youpi>better actually investigate what is actually happening

<damo22>i would like to gdb the driver and step through parts of it, but i need to attach root somehow without using the same controller

<youpi>you can just print

<youpi>people often shout "printf-debugging is hell", but I very much disaggree

<youpi>in low-level programming, managing to get gdb at the right point can take an awful lot of time, when a mere printf can give you the information you need quite quickly

<damo22>i cant believe we dont have printf in mach

<damo22>only print

<damo22>its so annoying too, i am tempted to implement that first

<damo22>mach_printf("value is %d\n", val);

<youpi>mach_print is intended to be something that you can essentially always call

<youpi>so no memory allocation etc.

<youpi>nobody contributed mach_printf yet, but it's a matter of somebody doing it

<youpi>I'm quite amazed how often I have to repeat this

<damo22>even if it allocates a static size of 500 bytes or something

<damo22>that would suffice for most usage

<youpi>I don't know if snprintf may not still allocate something?

<youpi>also, static allocation would not be thread-safe

<youpi>unless making it tls, but then you need tls to be working

<damo22>what about a macro that calls mach_print

<youpi>? that won't change the problems

<damo22>{ char wtf[500]; snprintf(wtf, 500, "value is %d", val); mach_print(wtf); }

<youpi>that'll be allocated on the stack

<youpi>you don't need a macro for that, it can be a mere function

<damo22>ok

<luckyluke>hi!

<luckyluke>is there currently a way to bootstrap a system using tmpfs instead of ext2fs?

<luckyluke>i.e. unpacking a (compressed) tar in a tmpfs, which would then run proc/auth/startup, then mount the root partition and do something like pivot_root

<luckyluke>if not, I might have a look at it after I finish the xstate patch for glibc :)

IRC channel logs

2025-01-17.log