These days, Intel's name is Mud in various circles because of the Spectre/Meltdown CPU flaws and other similar hardware issues that seem to be emerging as well. But, there was a recent discussion between some Intel folks and the kernel folks that was not related to those things. Some thrust-and-parry still was going on between kernel person and company person, but it seemed more to do with trying to get past marketing speak, than at wrestling over what Intel is doing to fix its longstanding hardware flaws.
Reinette Chatre of Intel posted a patch for a new chip feature called Cache Allocation Technology (CAT), which "enables a user to specify the amount of cache space into which an application can fill". Among other things, Reinette offered the disclaimer, "The cache pseudo-locking approach relies on generation-specific behavior of processors. It may provide benefits on certain processor generations, but is not guaranteed to be supported in the future."
Thomas Gleixner thought Intel's work looked very interesting and in general very useful, but he asked, "are you saying that the CAT mechanism might change radically in the future [that is, in future CPU chip designs] so that access to cached data in an allocated area which does not belong to the current executing context won't work anymore?"
Reinette replied, "Cache Pseudo-Locking is a model-specific feature so there may be some variation in if, or to what extent, current and future devices can support Cache Pseudo-Locking. CAT remains architectural."
Thomas replied, "that does NOT answer my question at all."
At this point, Gavin Hindman of Intel joined the discussion, saying:
Support in a current generation of a product line doesn't imply support in a future generation. Certainly we'll make every effort to carry support forward, and would adjust to any changes in CAT support, but we can't account for unforeseen future architectural changes that might block pseudo-locking use-cases on top of CAT.
And Thomas replied, "that's the real problem. We add something that gives us some form of isolation, but we don't know whether next generation CPUs will work. From a maintainability and usefulness POV, that's not a really great prospect."
Elsewhere in a parallel part of the discussion, Thomas asked, "Are there real world use cases that actually can benefit from this [CAT feature] and what are those applications supposed to do once the feature breaks with future generations of processors?"
Reinette replied, "This feature is model-specific with a few platforms supporting it at this time. Only platforms known to support Cache Pseudo-Locking will expose its resctrl interface."
To which Thomas said, "you deliberately avoided to answer my question again."
Gavin replied now, saying:
Reinette's not trying to avoid the questions, we just don't necessarily have definitive answers at this time. Currently pseudo-locking requires manual setup on the part of the integrator, so there will not be any invisible breakage when trying to port software expecting pseudo-locking to new devices, and we'll certainly do everything we can to minimize user-space/configuration impact on migration if things change going forward, but these are unknowns. We are in a bit of chicken/egg where people aren't broadly using it because it's not architectural, and it's not architectural because people aren't broadly using it. We could publicly carry the patches out of mainline, but our intent for pushing the patches to mainline are to a) increase exposure/usage, b) reduce divergence across people already using hacked versions, and c) ease the overhead in keeping patches in sync with the larger CAT infrastructure as it evolves - we are clear on the potential support burden being incurred by submitting a non-architectural feature, and there's certainly no intent to dump a science-experiment into mainline.
Thomas replied, "Ok. So what you are saying is that 'official' support should broaden the user base, which in turn might push it into the architectural realm. I'll go through the patch set with this in mind."
Elsewhere, Thomas and Reinette went through a more technical exchange of data, and Reinette provided useful data points for understanding the value of the CAT feature itself. To all of this, Thomas said, "Very nice. Thank you so much for doing this. That kind of data is really valuable. My take away from this: All of the mechanisms are only delivering best effort and the real benefit is the reduction of average latency. The worst case outliers are in the same ballpark at seems." And, he promised to review the next version of Intel's patch, which Reinette expected to send out within the week.
So as Intel tries to move past Spectre/Meltdown, it continues to collaborate with kernel developers on this sort of feature. At the same time, it's hard to forget that its hardware problems are not over, and that new CPU flaws continue to be discovered even now. Linus Torvalds has interpreted some of Intel's statements to mean that Intel does not intend to fix some of its hardware flaws in future generations of CPUs, which would force kernel developers, and developers of other operating systems, to work around those flaws for the foreseeable future. So there's a lot of tension even in the context of collaborating on relatively simple new features like CAT.
Green Hu posted a patch to support the NDS32 architecture. He described the current status as, "It is able to boot to shell and passes most LTP-2017 testsuites in nds32 AE3XX platform."
Arnd Bergmann approved the patch, but Linus Torvalds wanted a little more of a description—an overview of the "uses, quirks, reasons for existing" for this chip, to include in the changelog.
Arnd replied:
The non-marketing description is that this is a fairly conventional (in a good way) low-end RISC architecture that is usually integrated into custom microcontroller and SoC designs, competing with the similar ARM32, ARC, MIPS32, RISC-V, Xtensa and (currently under review) C-Sky architectures that occupy the same space. The most interesting bit from my perspective is that Andestech is already selling a new generation of CPU cores that are based on 32-bit and 64-bit RISC-V, but are still supporting enough customers on the existing cores to invest in both.
And Green also said:
Andes' nds32 architecture supports Linux for Andes' N10, D10, N13, N15, D15 processor cores.
Based on the patented 16/32-bit AndeStar RISC-like architecture, we designed the configurable AndesCore series of embedded processor families. AndesCores range from highly performance-efficient small-footprint cores for microcontrollers and deeply-embedded applications to 1GHz+ cores running Linux, covering general-purpose N-series cores for a wide range of computing needs; DSP-capable D-series cores for digital signal control; instruction-extensible E-series cores for application-specific acceleration; and secure S-series cores for best protection of the most valuable.
Our customers together have shipped over 2.5 billion SoCs with Andes processors embedded (including non-MMU IP cores). It will help our customers to get better Linux support if we are merged into mainline.
It looks like there's no controversy over this port, and it should fly into the main tree. One reason for the easy adoption is that it doesn't touch any other part of the kernel—if the patch breaks anything, it'll break only that one architecture, so there's very little risk in letting Green make his own choices about what to include and what to leave out. Linus' main threshold will probably be "does it compile?" If yes, then it's okay to go in.
The situation may start to become interesting if other parts of the kernel begin offering special behaviors for the NDS32 architecture, and if those behaviors start deviating too far from other architectures. For example, some architectures have special memory managing features that the kernel proper can take advantage of. Once NDS32 starts influencing code in other parts of the kernel, that likely would be the time Green's patches start to get a lot more scrutiny.
Note: if you're mentioned in this article and want to send a response, please send a message with your response text to ljeditor@linuxjournal.com, and we'll run it in the next Letters section and post it on the website as an addendum to the original article.
Zack Brown is a tech journalist at Linux Journal and Linux Magazine, and is a former author of the "Kernel Traffic" weekly newsletter and the "Learn Plover" stenographic typing tutorials. He first installed Slackware Linux in 1993 on his 386 with 8 megs of RAM and had his mind permanently blown by the Open Source community. He is the inventor of the Crumble pure strategy board game, which you can make yourself with a few pieces of cardboard. He also enjoys writing fiction, attempting animation, reforming Labanotation, designing and sewing his own clothes, learning French and spending time with friends'n'family.
