[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] news/2023-q4.mdwn: new qoth for q4 of 2023.

From: Luca
Subject: Re: [PATCH] news/2023-q4.mdwn: new qoth for q4 of 2023.
Date: Sat, 6 Jan 2024 22:15:44 +0100

Il 06/01/24 21:20, Sergey Bugaev ha scritto:
On Sat, Jan 6, 2024 at 10:47 PM jbranso@dismail.de <jbranso@dismail.de> wrote:
+Luca Dariz worked on adding [[some simple GNUMach user-space tests

I've never seen gnumach spelled like that (GNUMach), only GNU Mach or
gnumach. Is that intentional?
+Flavio Cruz [[improved GNUMach's
+by reordering `mach_msg_type_t` fields to byte align `msgt_name` and
+`msgt_size`.  He also created a patch series to [[avoid message
+resizing for
+He also [[removed untyped mach RPC
+since the Hurd always uses typed Mach RPC.

It's not that much that *the Hurd* uses typed IPC, it's that gnumach
does. The Hurd could easily support either, and in fact this support
was present (though likely bitrotten), and this is what Flavio has
removed. This is because going forward, we don't see the Hurd running
on any other flavor of Mach; but it was originally the goal for it to
run on non-GNU Machs, IIRC.

+Sergey Bugaev added [[GNUMach entry re-coalescing
+Essentially, Mach is not always able to merge two vm entries that are
+made next to each other, which slows down ext2 and bash.  Sergey
+allowed GNUMach to merge entries in the common cases, which greatly
+helps ext2fs.

Is that actually true though — did it speed anything up?

I reinstalled hurd-amd64 and it does seem faster than a few months ago, at least noticeable during a foreign debootstrap (on both 32 and 64-bit).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]