Thanks for the comments, Peter. I'll update the patch to address the syntax points. (Maybe checkpatch.pl should be updated to reflect your preferences?). About macros vs C. I agree with your preference. I used macros to be consistent with the existing code, and to be as backport friendly as possible. (a number of distros need to pull these patches into their supported kernels) Sure, I'm willing to write in a cosmetic-only patch, after the functional changes are upstream. > It would've been nice to have the CPUID instruction 1F leaf reference > 3B-3.9 in the SDM, and maybe mention this here too. I didn't mention SDM sections because they change -- leaving stale pointers in our commit messages. The SDM is re-published 4 times per year. > Also, figure 8-6 uses Q,R ID, without prior mention. Yeah, the tech-writer took my real example and turned it into a generic example. Probably a good idea, even if not gracefully executed. The point of undefined "Q" and "R" are that a new level can be invented at any time in the future, and the existing code that doesn't know about future levels should still function properly. The back-story is that Leaf-B was supposed to work this way, but the original SDM code example was hard-coded to assume 3-levels. Plenty of software was hard-coded and would have broken if we had actually added new levels to Leaf-B. And so Leaf-B had to be "forked" into Leaf-1F, with the implicit contract that only new code that can function properly in the face of unknown levels parses leaf-1F. Yes, the parsing routine in the Linux Kernel will work fine in the face of future unknown levels. Some utilities (such as cpuid), would have actually crashed if we added levels to Leaf-B. > You haven't explained, and I can't readily find it in the SDM either, > how these topology bits relate to caches and interconnects. > > Will these die thingies share LLC, or will LLC be per die. Will NUMA > span dies or not. Excellent question. Cache enumeration in Leaf-4 is totally unchanged. ACPI NUMA tables are totally unchanged. >From a scheduler point of view, imagine that a SKX system with 4 die in 4 packages was mechanically re-designed so that those 4 die resided in 2 double-sized packages. They may have tweaked the links between the die, but logically it is identical and compatible, and the legacy kernel will function properly. So the effect of Leaf B,1F is that it defines the scope of MSRs. eg. what processors does a die-scope MSR cover. That is why the rest of the patch is about sysfs topology, and about package MSR scope. Yes, there will be more exotic MSR situations in future products -- the first ones are pretty simple -- something called a package-scope-MSR in the SDM today becomes a die-scope-MSR in this generation on a multi-die/package system. It also reflects how many packages appear in sysfs, and this can effect licensing of some kinds of software. thanks, Len Brown, Intel Open Source Technology Center
