Hi! > > Well, it's all about how to actually route the changes and in general > > whenever avoidable we try to avoid whole-sale code replacement > > especially when most of the structural code is similar like in this > > case. Gradually evolving cfq to bfq is likely to take more work but > > I'm very positive that it'd definitely be a lot easier to merge the > > changes that way and people involved, including the developers and > > reviewers, would acquire a lot clearer picture of what's going on in > > the process. For example, AFAICS, most of the heuristics added by > > Would it make sense to merge bfq first, _then_ turn cfq into bfq, then > remove bfq? > > That way > > 1. Users like me would see improvements soon > > 2. BFQ would get more testing early. Like this: I applied patch over today's git... I only see last bits of panic... Call trace: __bfq_bfqq_expire bfq_bfqq_expire bfq_dispatch_requests sci_request_fn ... EIP: T.1839+0x26 Kernel panic - not syncing: Fatal exception in interrupt Shutting down cpus with NMI ... Will retry. Any ideas? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
