3 ms·

Current kernel and current distro tuning is almost always folly unless there's a specific issue you're trying to work around. Trying to squeeze a little more j

Current kernel and current distro tuning is almost always folly unless there's a specific issue you're trying to work around. Trying to squeeze a little more juice out of something is bound to come at the detriment of something else, or worse, break something else in unexpected ways. Basically, if the tunables aren't obvious in whatever default config you're using, the issue isn't in that config, it's that you're asking too much of your hardware and just need better hardware.

jeffbee 3y ago
> just need better hardware. That's .. yeah, that's completely false. I can think of dozens of things that are not right out of the box on any distro, on any hardware, in common practice. For example suppose you roll out Ubuntu on an EC2 instance, say a c6i.16xlarge, a 32C/64T, single-socket x86 server with a Nitro ENA. Where are the netrx interrupts delivered? Is RSS on/working? RPS, XPS? Interrupt coalescing? The distro can't make optimal choices for all use cases, but what they ship by default is a config that's not optimal for any use case. Literally nobody would consciously choose the defaults after thinking it over.
- n3storm 3y ago
  that is the free/open bsd (from what I know) thinking path and I love there are linux people that think on that terms too. not every year is the Linux on the Desktop year! :D
- bravetraveler 3y ago
  Most common example I can think of is 'net.core.somaxconn'. The default limit out of the box is laughably small. Has been for decades at this point.
  - Jach 3y ago
    Is 4096 still too small over 128? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=19f92a030ca6d772ab44b22ee6a01378a8cb32d4 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
    - jeffbee 3y ago
      According to that message, they lifted it to 4096 8 years ago, presumably for reasons. Have your systems got any bigger or faster since 2015?
    - bravetraveler 3y ago
      Nope, that's pretty decent ... this still hasn't made it to the distributions we're using, though. More specifically: the kernel releases. There's a lot in service pre 5.4. Hanging on by a thread. Relief is near.
toast0 3y ago
> Current kernel and current distro tuning is almost always folly unless there's a specific issue you're trying to work around. Of course there's no reason to tune if stock works fine. Plenty of people buy or a rent a reasonable computer and it has more than enough capacity for their work with default tuning. That's fine. But when you run out of CPU or memory or X, it's often a good idea to see if there's reasonable things you can do to get more out of the hardware you already have. Depending on what you're doing, there's often a lot of room for improvement. For some networking tasks, doing proper alignment of threads and work with Receive Side Scaling or similar can make a tremendous improvement in capacity versus naive threads. In some environments, the bandwidth costs when you're using enough capacity to see that mean that machine costs of doing it well versus naively don't matter, so you may as well do it naively and spend your engineering time elsewhere. In other environments, gettingthe same work done with 10% of the nodes is valuable. Also, in many cases, better hardware needs more tuning, rather than less. You don't need to spend a lot of time avoiding cross core communication on an 8-core single socket machine. But if you get a dual-socket, 128-core per socket machine and you're not careful about cross socket communication, you'll spend a lot of CPU on memory arbitration (which you'll have to know or learn how to look for)

jeffbee 3y ago

> just need better hardware. That's .. yeah, that's completely false. I can think of dozens of things that are not right out of the box on any distro, on any hardware, in common practice. For example suppose you roll out Ubuntu on an EC2 instance, say a c6i.16xlarge, a 32C/64T, single-socket x86 server with a Nitro ENA. Where are the netrx interrupts delivered? Is RSS on/working? RPS, XPS? Interrupt coalescing? The distro can't make optimal choices for all use cases, but what they ship by default is a config that's not optimal for any use case. Literally nobody would consciously choose the defaults after thinking it over.

n3storm 3y ago
that is the free/open bsd (from what I know) thinking path and I love there are linux people that think on that terms too. not every year is the Linux on the Desktop year! :D
bravetraveler 3y ago
Most common example I can think of is 'net.core.somaxconn'. The default limit out of the box is laughably small. Has been for decades at this point.
- Jach 3y ago
  Is 4096 still too small over 128? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=19f92a030ca6d772ab44b22ee6a01378a8cb32d4 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
  - jeffbee 3y ago
    According to that message, they lifted it to 4096 8 years ago, presumably for reasons. Have your systems got any bigger or faster since 2015?
  - bravetraveler 3y ago
    Nope, that's pretty decent ... this still hasn't made it to the distributions we're using, though. More specifically: the kernel releases. There's a lot in service pre 5.4. Hanging on by a thread. Relief is near.

toast0 3y ago

> Current kernel and current distro tuning is almost always folly unless there's a specific issue you're trying to work around. Of course there's no reason to tune if stock works fine. Plenty of people buy or a rent a reasonable computer and it has more than enough capacity for their work with default tuning. That's fine. But when you run out of CPU or memory or X, it's often a good idea to see if there's reasonable things you can do to get more out of the hardware you already have. Depending on what you're doing, there's often a lot of room for improvement. For some networking tasks, doing proper alignment of threads and work with Receive Side Scaling or similar can make a tremendous improvement in capacity versus naive threads. In some environments, the bandwidth costs when you're using enough capacity to see that mean that machine costs of doing it well versus naively don't matter, so you may as well do it naively and spend your engineering time elsewhere. In other environments, gettingthe same work done with 10% of the nodes is valuable. Also, in many cases, better hardware needs more tuning, rather than less. You don't need to spend a lot of time avoiding cross core communication on an 8-core single socket machine. But if you get a dual-socket, 128-core per socket machine and you're not careful about cross socket communication, you'll spend a lot of CPU on memory arbitration (which you'll have to know or learn how to look for)