... >> There have been discussions about this in the past and iirc, most people > agree >> about not going the byos* route. But I am still all for such a proposal > and if >> it's good/clean enough, I think we can definitely tear down what we have > and >> throw it away! The I/O scheduling part is intrusive enough that even the > current >> code base has to be changed quite a bit. > > The "byos" route seems more promising with respect to possible performance > gains, but it will definitely add complexity, and I cannot say if the > added complexity will be worth performance improvements. > > Meanwhile, I'd suggest we better understand what causes regression with > your current patches and maybe then we'll be smarter to get to the right > direction. :) > Agreed, let's try to understand the cause of the "underperformance" with wqs. I disabled WQ_CGROUPS that effectively disables my changes and I can still consistently reproduce the lower numbers. >> *byos = bring your own scheduling ;) >> >> > Thanks. > > -- > Sincerely yours, > Mike. > > [1] https://lwn.net/Articles/650857/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
