> On 09/03/08 17:07, Vikram Hegde wrote: > > Hi, > > > >> Abilities to disable the IOMMU as a choice? > Performance impact on > >> various systems and interactions with other > projects that have gone > >> to some length to work within S/G and its > performance > >> characteristics. How will this affect them? Cache > effects? > >> Interactions with some VM work currently being > undertaken? > >> > >> I can't imagine such a major change being > closed/approved/automatic. > > Performance is driver dependant. There is no way a > single project team > > can test the gamut of drivers out there and certify > that the IOMMU > > will give acceptable performance for all needs > (which is itself a > > subjective opinion). > > No, it's a measurable value- not subjective.
Lacking the theoretical background, I'd still like to make an observation based on real-world experience: performance is objective in a practical sense if and only if: * valid comparisons (not apples-to-oranges) can be made * said comparisons can also be _replicated_ on demand This leads to two further notions: * the instrumentation has to be up to the task - that may mean this should include additional instrumentation as needed * some broad problems have been demonstrated to be unsolvable in the general case (halting problem, incompleteness theorems, etc). While any specific case of a perceived performance problem may be repeatable when narrowing the focus sufficiently, it just might be a bit presumptuous to assume that to be the case for all real-world hardware configurations, workloads, etc. The mere explosion of combinations might be enough to at least make that unfeasible. Which if anything may make the ability to selectively disable new functionality all the more important. Which leads me just now to think of one last point: it would be interesting to see references to (or applicability of) "lessons learned" in the course of other implementations of IOMMU support. Many aspects of Solaris have probably benefitted in terms of architectural sophistication from previous ports; if this is an area where such functionality has up to now been under pretty much single control over hardware and software design, it may include opportunities and challenges greater than those of (for example) typical driver ports, in terms of evolving the OS architecture. So I think that there is a real opportunity here to capture perhaps a bit more than usual of documentation of design choices and rationales as this develops, which could not only help in terms of its own long-term development and maintenance, but set or expand a precedent for future endeavors of similar scope, as well as to further open (to observation, at least) the development process. -- This message posted from opensolaris.org
