In my opinion, machvec is a bad idea for a temporary workaround. You'll need to create new header files etc etc all just for a short-lived workaround. Just my 2 cents. --david On 9/5/07, Natalie Protasevich <protasnb@xxxxxxxxx> wrote: > On 9/5/07, Robin Holt <holt@xxxxxxx> wrote: > > > No :) those interested are big hardware makers of large scaled out > > > boxes, such as HP, UIS. They are using own asics and are not > > > necessarily being able to keep chipset native capabilities intact. As > > > I said in the preamble, the mechanism has to be there so they can turn > > > the ptc.g off and run the OS. > > > > This really sounds like it is best done as a machvec. Currently, Altix > > (sn2) does not have a ptc.g that spans nodes. We have our own tlb purge > > mechanism which is very flexible and scalable. Maybe it would be best > > to follow that example. To repeat Bjorn's comments, this area can be > > fraught with _VERY_ difficult to diagnose problems. A boot test can > > hardly be expected to uncover all the races so be patient while we walk > > through this code. > > > All right, all right ... :) I'll do the machvec then. Thanks guys, > will peek into the sn2 to get an idea. > > Regards, > --Natalie > - > To unsubscribe from this list: send the line "unsubscribe linux-ia64" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Mosberger Consulting LLC, http://www.mosberger-consulting.com/ - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|