Mark.Haywood wrote: > Li, Aubrey wrote: >> Li, Aubrey wrote: >> >> >>>> Mark Haywood <> wrote: >>>> >>>>> Mark Haywood wrote: >>>>> >>>>>> Li, Aubrey wrote: >>>>>> >>>>>>> Hi Andrei, >>>>>>> >>>>>>> Andrei Dorofeev wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Aubrey, >>>>>>>> >>>>>>>> What version of the X8DTN BIOS are you using? I have filed >>>>>>>> this issue back in February on premier.intel.com and it >>>>>>>> should've been resolved by now. Do you see this with BIOS >>>>>>>> version 3059W? >>>>>>>> >>>>>>>> >>>>>>> Right, right, the version is 3059W! And this is the newest >>>>>>> version. From the BIOS changelog, they tested windows, redhat >>>>>>> linux, I'm not sure if they care about what solaris reported, :( >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Don't give up on using _PSD because of this. >>>>>>>> >>>>>>>> >>>>>>> I believe before NHM, _PSD is seldom implemented. Using the >>>>>>> vendor specific CPU topology should be an acceptable way to >>>>>>> build domain info. I admit I don't have the knowledge about the >>>>>>> other CPU vendor, like SPARC and AMD, what's the benefit of >>>>>>> using _PSD? Othering than introducing panic, ;) >>>>>>> >>>>>>> >>>>>> That's a very good question. What is the benefit of the _PSD? I >>>>>> believe the _PSD was introduced to prevent Solaris and other >>>>>> operating systems from having to do exactly what you are >>>>>> proposing (i.e., introducing vendor specific details of >>>>>> processor state domains into the operating system). The _PSD is >>>>>> supposed to define a standard way for operating systems to >>>>>> digest the domain data. Unless there is a really compelling >>>>>> reason to ignore the _PSD, I would suggest that we continue to >>>>>> use it. >>>>>> >>>>> How about a compromise. Since the _PSD often doesn't exist, we >>>>> have to be able to determine the domains from the topology. Since >>>>> we have to do this anyway, why don't we digest the _PSD and >>>>> verify it afterwards using the topology. Why do this? So that we >>>>> can report bad _PSDs to the BIOS developers so that the _PSDs >>>>> become more reliable in the future. If a faulty _PSD is >>>>> identified we can log a message to the console and use domains >>>>> built from the topology. At some point it would be nice if we >>>>> didn't have to continue determining the domains using topology. >>>>> Sound reasonable? >>>>> >>>> That sounds a good suggestion. In early stage, we may need to >>>> reveal bugs in BIOS implementation and push BIOS to behave >>>> correctly. Eventually BIOS should be robust enough so we could >>>> switch to BIOS. If we give up _PSD, it seems we are on the >>>> opposite side of >>>> ACPI spect then. >>>> >>>> >>> BIOS is not ACPI, hehe. If we use topology to check, why not >>> use it at all? >>> why we need to verify BIOS bug? Anyway, the suggestion works to me. >>> >>> Thanks, >>> -Aubrey >>> >> >> Wait a minute, I remember some platform has sub-domain in a package, >> I wonder how do you want to verify if _PSD is right or not? >> > > Are you suggesting that we can't verify the domains using the > topology? If so, then I don't see how we could create the domains > from the topology either. BTW, it is this type of complexity (and the > possibility that the complexity will increase in the future) that > makes me believe we should try to use the _PSD if possible. >
No, I'm not suggesting. I also wonder is there a platform that several packages belong to the same domain? I just want to know when we verify the _PSD, can we do some vendor specific more than cpu topology? I'm worried _PSD becomes wrong after topology checking. Thanks, -Aubrey
