public inbox for [email protected]
help / color / mirror / Atom feedFrom: Samuel Thibault <[email protected]>
To: Thomas Munro <[email protected]>
Cc: Michael Banck <[email protected]>
Cc: Alexander Lakhin <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: [email protected]
Subject: Re: GNU/Hurd portability patches
Date: Fri, 21 Nov 2025 01:54:29 +0100
Message-ID: <aR-4ReXSfSl_YCfe@end> (raw)
In-Reply-To: <CA+hUKGKYoATxDq5Gp+JxG=X2=Zk=h=ZZ3+AwHmXBE559JJChmw@mail.gmail.com>
References: <[email protected]>
<CA+hUKGKo6rToAxyObEnOnOiT3QEJuJFVkVNqikw0wVFHag=3Fg@mail.gmail.com>
<[email protected]>
<CA+hUKGLvrBt9bkjiHb8VOTGOsKfL6W0ik1+h0M1E5TSy1=QmJg@mail.gmail.com>
<[email protected]>
<CA+hUKGKAUa7ybQ9=6ap2uh-TmHtH8wFL-DTeeh-swprg+Rf=+w@mail.gmail.com>
<aRuwX88mdP8tfuvi@end>
<CA+hUKGKD0EOviHPG_W5gBZ+xiRFktvn=tBebrSBf8oQDecKnwA@mail.gmail.com>
<aR5Ic421-i4V1SPb@end>
<CA+hUKGKYoATxDq5Gp+JxG=X2=Zk=h=ZZ3+AwHmXBE559JJChmw@mail.gmail.com>
Hello,
Thomas Munro, le jeu. 20 nov. 2025 17:20:57 +1300, a ecrit:
> On Thu, Nov 20, 2025 at 11:45 AM Samuel Thibault
> <[email protected]> wrote:
> > Thomas Munro, le mar. 18 nov. 2025 18:32:38 +1300, a ecrit:
> > > Does that also imply that preadv() has to loop over the vectors
> > > sending tons of messages and waiting for replies?
> >
> > Currently glibc's preadv performs copies.
>
> Even without O_DIRECT (= potential scatter/gather DMA to/from user
> space), the kernel/server still seems like a better place to put a
> scatter/gather-with-memcpy() loop,
I'm not saying the current behavior is optimized :)
> > > (And then to get more and more pie-in-the-sky: (1) O_DIRECT is highly
> > > desirable for zero-copy DMA to/from a user space buffer pool,
> >
> > We don't currently have that defined.
>
> . o O { Is anyone trying to put ext4 or xfs into a Hurd server? }
The idea would be to leverage the FreeBSD implementation through the
rump layer.
> > > (2) starting more than one I/O with a single context switch and likewise
> > > for consuming replies,
> >
> > That would be possible by introducing in gnumach a multi-message variant
> > of the mach_msg() system call.
>
> . o O { If I were designing a new mach_msgs() I'd also be tempted to
> try to make it so that the messages don't have have to be copied in
> during the system call, but instead can be accessed directly by the
> receiver,
That's already what happens: for out-of-line data, mach maps-in/out the
data pages through the RPC.
Samuel
view thread (50+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: GNU/Hurd portability patches
In-Reply-To: <aR-4ReXSfSl_YCfe@end>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox