On 2024-10-17, 04:11, "Peter Zijlstra" <peterz@xxxxxxxxxxxxx> wrote: >> For example, running mysql+hammerdb results in a 12-17% throughput > Gautham, is this a benchmark you're running? Most of my testing for this investigation is on mysql+hammerdb because it simplifies differentiating statistically meaningful results, but performance impact (and improvement from disabling the two features) also shows on workloads based on postgresql and on wordpress+nginx. > How does using SCHED_BATCH compare? I haven't tested with SCHED_BATCH yet, will update the thread with results as they accumulate (each variation of the test takes multiple hours, not counting result processing and evaluation). Looking at man sched for SCHED_BATCH: "the scheduler will apply a small scheduling penalty with respect to wakeup behavior, so that this thread is mildly disfavored in scheduling decisions". Would this correctly translate to "the thread will run more deterministically, but be scheduled less frequently than other threads", i.e. expectedly lower performance in exchange for less variability? > So disabling them by default will undoubtedly affect a ton of other > workloads. That's very likely either way, as the testing space is near infinite, but it seems more practical to first address the issue we already know about. At this time, I don't have any data points to indicate a negative impact of disabling them for popular production workloads (as opposed to the flip case). More testing is in progress (looking at the major areas: workloads heavy on CPU, RAM, disk, and networking); so far, the results show no downside. > And sysctl is arguably more of an ABI than debugfs, which > doesn't really sound suitable for workaround. > > And I don't see how adding a line to /etc/rc.local is harder than adding > a line to /etc/sysctl.conf Adding a line is equally difficult both ways, you're right. But aren't most distros better equipped to manage (persist, modify, automate) sysctl parameters in a standardized manner? Whereas rc.local seems more "individual need / edge case" oriented. For instance: changes are done by editing the file, which is poorly scriptable (unlike the sysctl command, which is a unified interface that reconciles changes); the load order is also typically late in the boot stage, making it not an ideal place for settings that affect system processes.
|