IRC channel logs


back to list of logs

<damo22>has anyone been working on doing the actual removal of linux/ from gnumach?
<damo22>are we at that point yet?
<youpi>gnumach can be built fine without linux/ yes
<youpi>for now rumpdisk still consumes too much memory before being able to enable it by default
<youpi>one "detail" is that the 128MB heap is locked-in in memory
<youpi>we'd need to change the sbrk/mmap allocation to avoid that
<damo22>how does gnumach disk driver avoid consuming so much ram
<youpi>that's a long-standing concern that we don't control that much how sbrk/mmap are layed out in memory
<youpi>it just doen't allocate it
<youpi>while in hurd, all processes have a 128MB reserved heap
<youpi>that's not usually a problem
<youpi>unless you use mlockall
<youpi>which rumpdisk does
<youpi>also, there is the todo about asynchronous requests
<damo22>how does async io work? is it difficult to do?
<youpi>that'd avoid piling up threads when running multiple requests
<youpi>it's not very difficule
<youpi>it's just about calling aoi_read
<youpi>and keeping a list of request
<youpi>gotrta go
<Pellescours>damo22: I have a branch with the linux code removed
<Pellescours>but can we before add a driver to be able to start in ide/ata? Because it’s the default mount option for qemu and if we remove completely support for it, a lot of pœple will complain about it
<youpi>sure we'll have to do this
<youpi>(note: there's a --disable-linux-groups option)
<damo22>yeah ok
<damo22>i *think* it could be as simple as linking with libpcidev_piixide
<damo22>when compiling rumpdisk
<curiosa>Hi, since I've seen from the logs that you are making a list of what is missing to get rid of the kernel space disk driver, I would like to add two things
<curiosa>The first one is a functioning cdrom driver
<curiosa>The second one, maybe, it is a transition plan that will allow people to upgrade without breaking their system: perhaps just keeping two version of gnumach in repositories for a while and a deprecation deadline will suffice
<youpi>the cdrom driver works
<youpi>in sata mode
<youpi>probably the ide driver will drive them fine
<youpi>yes, the transition plan is definitely needed
<youpi>a deprecation deadline may not really be enough, if we want people to be able to upgrade from their Debian Hurd 2021 system into Debian Hurd 2023
<luckyluke>Hi, is there some benchmark available for mach_msg()? I see there are a lot of special cases, I wonder if it could be simplified
<youpi>at the time that was benchmarked and that was why they wrote the special cases
<luckyluke>do you think it still makes sense to keep these optimizations? I see xnu drastically simplified the code for mach_msg()
<youpi>I don't know, benchmarks can tell
<youpi>possibly that part of the code is not what eats most of the time, and rather the page mapping management / data copy
<youpi>but at the same time people get excited with L4 and such which precisly benchmarks smallish IPCs, which do benefit from such optimizations
<luckyluke>I'll try to do some measurements, I'm slowly writing a sort of unit tests for gnumach, to run under qemu as bootstrap modules :)