Messages in this thread | | | Date | Wed, 7 Oct 2020 14:01:25 +0100 | From | Mel Gorman <> | Subject | Re: [RFC PATCH] kernel: allow to configure PREEMPT_NONE, PREEMPT_VOLUNTARY on kernel command line |
| |
On Wed, Oct 07, 2020 at 02:29:23PM +0200, Michal Hocko wrote: > On Wed 07-10-20 14:19:39, Peter Zijlstra wrote: > > On Wed, Oct 07, 2020 at 02:04:01PM +0200, Michal Hocko wrote: > > > From: Michal Hocko <mhocko@suse.com> > > > > > > Many people are still relying on pre built distribution kernels and so > > > distributions have to provide mutliple kernel flavors to offer different > > > preemption models. Most of them are providing PREEMPT_NONE for typical > > > server deployments and PREEMPT_VOLUNTARY for desktop users. > > > > Is there actually a benefit to NONE? We were recently talking about > > removing it. > > I believe Mel can provide much better insight. We have been historically using > PREEMPT_NONE for our enterprise customers mostly for nice throughput > numbers. Many users are really targeting throughput much more than > latencies. My understanding is that even though VOLUNTARY preemption model > doesn't add too many preemption points on top of NONE it is still > something that is observable (IIRC 2-3% on hackbench). >
It's marginal from the tests I ran but that was based on 5.3. At worst, it looked like roughly a hit but a lot of loads simply didn't notice. However, it might vary between architectures that I cannot cover or workloads that I didn't consider. As the impact of PREEMPT_VOLUNTARY depends on where cond_resched and might_sleep is used, it's also something that can vary over time. The intent was that by having the command-line switch, a user could test the switch if there was a suspicion that a regression was related to PREEMPT_VOLUNTARY as opposed to telling them "tough, that's the reality now".
-- Mel Gorman SUSE Labs
| |