[HN Gopher] Using io_uring to make a high-performance finger server
___________________________________________________________________
Using io_uring to make a high-performance finger server
Author : smlckz
Score : 62 points
Date : 2021-05-24 11:31 UTC (11 hours ago)
(HTM) web link (drewdevault.com)
(TXT) w3m dump (drewdevault.com)
| rwmj wrote:
| I'm missing some "high level" context about io_uring, I might as
| well ask here:
|
| - If I want to write a multithreaded program, is it best to have
| one io_uring per thread?
|
| - Per CPU core?
|
| - Per device or PCIe lane to the device? (It might make sense
| ...)
|
| - Or one for the whole program? (Will Linux distribute requests
| across cores and run them in parallel for me?)
|
| - If I'm writing a library that uses io_uring, should I create my
| own io_uring or offer an interface to add requests to one which
| the main program creates? (Or perhaps both?)
| anarazel wrote:
| > - If I want to write a multithreaded program, is it best to
| have one io_uring per thread?
|
| Yes! But it's not quite that simple: Sometimes you might need
| some of the ordering operations in io_uring, which then will
| force you to use a separate (possibly dedicated) ring for that.
| Typical cases might be a database's journal.
|
| If you use multiple threads (or processes) to access the same
| ring you'll need synchronization around submission / completion
| (potentially separately). Avoiding that when not necessary is
| obviously good.
|
| > - Per CPU core?
|
| That'll depend heavily on your program. If you have a program
| which has tasks running on specific CPUs, yes, that can make
| sense - but at that point it's basically a subset of the muti-
| threaded program question.
|
| > - Per device or PCIe lane to the device? (It might make sense
| ...)
|
| Hm. I think that will effectively also boil down to the per-
| task thing above. Particularly if you use polling it's good to
| be on the actual NUMA node the PCIe device is attached too.
|
| > - Or one for the whole program? (Will Linux distribute
| requests across cores and run them in parallel for me?)
|
| I think that'll depend on the type of device. For e.g. NVMe
| devices, there'll be multiple hardware queues. The CPU the
| submitter is on will determine which hardware queue is used
| (and that in turn will influence the interrupt location, at
| least by default).
|
| > - If I'm writing a library that uses io_uring, should I
| create my own io_uring or offer an interface to add requests to
| one which the main program creates? (Or perhaps both?)
|
| I don't think there's a generic answer to this one. It'll
| heavily depend on the type of library.
|
| Caveat: I've used io_uring a bunch, read some of the code, but
| I'm not an authority on it.
| hawski wrote:
| For confused people: it's written in author's language Hare. The
| language uses QBE as backend [2]. I wonder what author has
| against Zig (probably at least current dependence on LLVM). It
| reminds me of Myrddin [3], which AFAIR is connected to Suckless
| folks.
|
| [1] https://harelang.org/
|
| [2] https://c9x.me/compile/
|
| [3] https://myrlang.org/
|
| [4] https://suckless.org/
| donkarma wrote:
| What is the point? We don't need another systems programming
| language. We've got D, Rust, Zig, and C, and to be honest it
| just looks like a worse C.
| kristoff_it wrote:
| > I wonder what author has against Zig (probably at least
| current dependence on LLVM)
|
| Here are some opinions shared by ddevault:
| https://news.ycombinator.com/item?id=15494222
| Zababa wrote:
| const grent = match (passwd::getgroup(group)) { void =>
| fmt::fatal("No '{}' group available", group), gr:
| passwd::grent => gr, };
|
| Interesting, is void being used as the "None" of an option type
| here? At least that's what it looks like to me.
| Zababa wrote:
| I tried to use finger in Ubuntu, and it doesn't display UTF-8
| correctly. It seems that a patch would fix this but it's been
| untouched for 6 years
| https://bugs.launchpad.net/ubuntu/+source/bsd-finger/+bug/46...
___________________________________________________________________
(page generated 2021-05-24 23:01 UTC)