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
