> No, I've no figures to provide here. The background of this dist_eqs > option is actually to allow us testing across all event queues > without to change the testcases resp consumers to use certain > event queue number. Thus, I should comment it as EXPERIMENTAL?
Seems like it's just development/testing code that shouldn't escape into the wild? > > I think I would rather hold off on multiple EQs for this merge window > > and plan on having something really solid and thought-out for 2.6.24. > Fair enough. However why don't let us gather experience with this > feature now? Should we remove dist_eqs option for more consistency? As I said I definitely think the dist_eqs switch doesn't sound like something we want to expose to people. With that said I still am not sure about putting the multiple EQs feature in this release. All the infrastructure is there to make experimenting with it fairly painless (just the low-level driver needs to change), and I still haven't seen much code using the feature or even any anecdotal information about the performance impact. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
