IRC channel logs

<ZhaoM>morning

<damo22>DHCPDISCOVER on /dev/wm0 to 255.255.255.255 port 67 interval 7

<damo22>sending packet: [ OK ] 342

<damo22>irq handler [11]: release a dead delivery port e8bb4008 entry dc255df8

<damo22>irq handler [11]: still 1 unacked irqs in entry dc255df8

<damo22>dtal=342 capl=342 hdrl=18

<damo22>exactly one packet

<damo22>ff ff ff ff ff ff 52 54 00 12 34 56 08 00 rcvd a packet : [ OK ] 342

<damo22>seems like the irq handler times out and drops the irq

<sneek>Welcome back damo22!!

<ZhaoM>it seems some failed vim tests are due to hurd is not efficient enough

<ZhaoM>I think they will pass after SMP is implemented

<ZhaoM>this one needs to be solved https://github.com/vim/vim/blob/master/src/testdir/test_functions.vim#L2773

<ZhaoM>our uname: GNU matches the regex, so the test expects has('bsd').

<ZhaoM>making that regex stricter should solve the issue

<gfleury>ZhaoM: you need to add GNU since the regex you mention try match GNU/kFreeBSD

<gfleury>ZhaoM: you Can try smp expect for smp 2

<solid_black>hi!

<sneek>Welcome back solid_black, you have 2 messages!

<sneek>solid_black, youpi says: thinking about the writeback, writing it ahead of time sure is welcome, but missing doing that should not be a reason for hanging. We need to be sure that even if there is a very fast-writer, we don't hang. I.e. at some point somehow block writers while ext2fs & rumpdisk are writing stuff back. Then writing back ahead of time is just an optimization to make it overlapped rather that blocking wri

<sneek>solid_black, damo22 says: i think it's getting to the point where it would be very useful to have your proposed new startup mechanism written

<solid_black>oh wow, I must have missed a bunch of interesting discussions here

<solid_black>re writeback: it would be nice not to hang indeed, but what do you do if writing back involves allocating more pages, and there are none?

<solid_black>one option is making ext2fs & rumpdisk themselves "VM privileged", i.e. allowing them to allocate pages even where there are little left

<solid_black>the other thing I dislike is that Mach apparently enters a *mode* where it blocks new page allocations until the pages being written back are in fact released

<solid_black>I would expect it to only block until *some* page frees up, not necesserily the very physical page used for writeback

<ZhaoM>gfleury: ah my bad, the issue is that `has('bsd')` returns 1

<ZhaoM>nothing about regex

<solid_black>(hi ZhaoM!)

<ZhaoM>hi solid_black

<damo22>hi solid_black

<solid_black>hi damo22!

<damo22>happy holiday season, returning back to normal?

<solid_black>what was the english term for throttling producers so consumers can keep up?

<damo22>denial of service

<damo22>:P

<ZhaoM>gfleury: and yeah I'm also wondering if we should add GNU platform in that test

<solid_black>backpressure! that's the word I'm looking for

<solid_black>yes, so what I'm trying to say is that there's already a natural backpressure mechanism for writeback

<solid_black>w/ queue limits of pager ports

<gfleury>ZhaoM: i think we should add it

<solid_black>so if the pager (ext2fs) cannot keep up with pageout requests, new pageout requests aren't queued to infinity, instead there's just shortage of pages

<solid_black>but all of this is brittle and something is evidently broken

<solid_black>the good news is I did understand all the things about "copy objects" and shadows and the various CoW modes

<solid_black>which means I can make changes with some confidence

<ZhaoM>gfleury: call assert_equal(uname =~? 'GNU', has('hurd')) ?

<ZhaoM>and we need add has('hurd') of course

<ZhaoM>I add that to my TODO list

<ZhaoM>gfleury: (about smp 2) I will try it

<youpi>ZhaoM: is vim multithreaded? otherwise smp won't help

<youpi>solid_black: ext2fs & rumpdisk are supposed to be privileged so they can take from the reserved area, yes. I don't know if that notion survived richard's rewrite

<gfleury>ZhaoM: not smp 2 but you Can do smp 3 4 ...

<gfleury>7,99ZhaoM99,99: smp 2 has a race

<solid_black>in unrelated news, a lot of my layout work has been merged into GTK main, and will be a part of GTK 4.18, so rejoice :D

<ZhaoM>youpi: indeed it seems vim is single threaded

<ZhaoM>gfleury: got it

<ZhaoM>but setting longer test sleep time can exactly pass the tests

<ZhaoM>maybe submitting the extending sleep time patches to debian is the best method

<gfleury>solid_black: congrats for your work gtk :(

<solid_black>why the ":("? :D

<gfleury>solid_blac: you know what i dumb in making emoji with those caracter. It just a smile.

<gfleury>solid_black: oops i type a wrong nikname

<youpi>sneek: later tell solid_black 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

<sneek>Will do.

<youpi>sneek: botsnack

<sneek>:)

IRC channel logs

2025-01-14.log