In search of an appropriate RLIMIT_MEMLOCK default

Posted Nov 20, 2021 20:11 UTC (Sat) by Sesse (subscriber, #53779)
In reply to: In search of an appropriate RLIMIT_MEMLOCK default by Lionel_Debroux
Parent article: In search of an appropriate RLIMIT_MEMLOCK default

io_uring is very much relevant even for spinning rust, though.

In search of an appropriate RLIMIT_MEMLOCK default

Posted Nov 20, 2021 21:25 UTC (Sat) by andresfreund (subscriber, #69562) [Link] (3 responses)

Efficient completion (rather than readiness) based network IO is also useful in a lot of situations that do not involve meaningful amounts of disk IO. And doing that while not wasting memory requires requires registered buffers...

In search of an appropriate RLIMIT_MEMLOCK default

Posted Nov 20, 2021 21:33 UTC (Sat) by Sesse (subscriber, #53779) [Link] (2 responses)

I think I might have missed something about how to use io_uring with network I/O, though. Are you still supposed to use epoll to check for readiness? I mean, you can't just fire off read() or send() (as appropriate) for every socket, since the ring is of finite size, right?

In search of an appropriate RLIMIT_MEMLOCK default

Posted Nov 20, 2021 22:05 UTC (Sat) by andresfreund (subscriber, #69562) [Link] (1 responses)

Network IO that internally is waiting doesn't take up a ring entry. Of course that opens up the danger that there are completions that don't fit the ring - which has been addressed by storing overflowing completions off ring (there's a feature flag to test for for this).

There's a second issue with just using readiness for receiving network data: The amount of buffer space that requires. Newer kernel version address that by providing buffer space that isn'tt associated with a specific IO that are used when needed. But that buffer space IIRC is counted as locked.

In search of an appropriate RLIMIT_MEMLOCK default

Posted Nov 20, 2021 22:19 UTC (Sat) by andresfreund (subscriber, #69562) [Link]

See https://lwn.net/Articles/815491/