[HN Gopher] Shinjuku: Preemptive Scheduling for msecond-scale Ta...
___________________________________________________________________
Shinjuku: Preemptive Scheduling for msecond-scale Tail Latency
[pdf]
Author : mlerner
Score : 22 points
Date : 2021-12-19 01:28 UTC (21 hours ago)
(HTM) web link (www.usenix.org)
(TXT) w3m dump (www.usenix.org)
| eternalban wrote:
| Some related (TILs for me) from the paper:
|
| NIC RSS: https://medium.com/@anubhavchoudhary/introduction-to-
| receive...
|
| Dune: http://dune.scs.stanford.edu/
| toast0 wrote:
| RSS (recieve side scaling) is pretty magic, if your stack is
| setup for it, and it makes sense for your application. Windows
| may have done it best, but FreeBSD's support is OK, if you're
| willing to fiddle with it.
|
| You end up with everything for a given connection happening on
| the same cpu, so you have a ton less inter cpu communications
| and lock contention. NIC interrupt/queue, TCP kernel state,
| userland state, etc. Of course, if you've got bottlenecks other
| than syscalls/networking, the improvements might not make much
| difference. And, there's not a lot of reported use, so their
| may be rough edges, such as you need to implement it in the
| daemons you use, and if you make outgoing connections, you've
| got to manually bind ports to ensure they're RSS aligned.
|
| Also, if your setup is standardized hardware for all servers,
| you'll run into issues like RSS has power of two threads, but
| your standard server doesn't have a power of two CPUs, or your
| nics can do 16 RSS queues, and you've got more CPUs so they're
| just idle. Probably NUMA issues if you're running multi-socket
| systems.
___________________________________________________________________
(page generated 2021-12-19 23:01 UTC)