On Tue, Dec 13, 2022 at 06:11:38PM -0800, Josh Don wrote: > Improving scheduling performance requires rapid iteration to explore > new policies and tune parameters, especially as hardware becomes more > heterogeneous, and applications become more complex. Waiting months > between evaluating scheduler policy changes is simply not scalable, > but this is the reality with large fleets that require time for > testing, qualification, and progressive rollout. The security angle > should be clear from how involved it was to integrate core scheduling, > for example. Surely you can evaluate stuff on a small subset of machines -- I'm fairly sure I've had google and facebook people tell me they do just that, roll out the test kernel on tens to hundreds of thousand of machines instead of the stupid number and see how it behaves there. Statistics has something here I think, you can get a reliable representation of stuff without having to sample *everyone*. I was given to believe this was a fairly rapid process. Just because you guys have more machines than is reasonable, doesn't mean we have to put BPF everywhere. Additionally, we don't merge and ship everybodies random debug patch either -- you're free to do whatever you need to iterate on your own and then send the patches that result from this experiment upstream. This is how development works, no?
