长期支持版本

    社区创新版本

      关键特性

      AI专项

      智能时代,操作系统需要面向AI不断演进。一方面,在操作系统开发、部署、运维全流程以AI加持,让操作系统更智能;另一方面,openEuler已支持Arm,x86,RISC-V等全部主流通用计算架构,在智能时代,openEuler也率先支持NVIDIA、昇腾等主流AI处理器,成为使能多样性算力的首选。

      • OS for AI:openEuler兼容NVIDIA、Ascend等主流算力平台的软件栈,为用户提供高效的开发运行环境。通过将不同AI算力平台的软件栈进行容器化封装,即可简化用户部署过程,提供开箱即用的体验。同时,openEuler也提供丰富的AI框架,方便大家快速在openEuler上使用AI能力。

        • openEuler已兼容CANN、CUDA等硬件SDK,以及TensorFlow、PyTorch等相应的AI框架软件,支持AI应用在openEuler上高效开发与运行。
        • openEuler AI软件栈容器化封装优化环境部署过程,并面向不同场景提供以下三类容器镜像。
          1. SDK镜像:以openEuler为基础镜像,安装相应硬件平台的SDK,如Ascend平台的CANN或NVIDIA的CUDA软件。
          2. AI框架镜像:以SDK镜像为基础,安装AI框架软件,如PyTorch或TensorFlow。
          3. 模型应用镜像:在AI框架镜像的基础上,包含完整的工具链和模型应用。

        相关使用方式请参考openEuler AI 容器镜像用户指南

      • AI for OS:当前,欧拉和AI深度结合,一方面使用基础大模型,基于大量欧拉操作系统的代码和数据,训练出EulerCopilot,初步实现代码辅助生成、智能问题智能分析、系统辅助运维等功能,让openEuler更智能。EulerCopilot-智能问答:EulerCopilot智能问答平台目前支持web和智能shell两个入口。

        1. Web入口:操作简单,可咨询操作系统相关基础知识,openEuler动态数据、openEuler运维问题解决方案、openEuler项目介绍与使用指导等等。
        2. 智能Shell入口:自然语言和openEuler交互,启发式的运维。

        相关使用方式请参考EulerCopilot-智能问答使用指南

      AI for Compiler

      AI For Compiler框架接受编译器相关信息作为输入,在框架内部进行编译器信息解析和ONNX环境准备之后,向ONNX模型发送推理请求。ONNX模型将根据编译器信息进行推理,并将推理结果返回AI For Compiler框架。AI For Compiler框架对推理结果进行解析、处理,将处理后的结果返回编译器,用于指导多种优化手段的实施。

      openEuler Embedded

      openEuler Embedded 围绕工业和机器人领域持续深耕,通过行业项目垂直打通,不断完善和丰富嵌入式技术栈和生态。openEuler 22.03 LTS SP4 Embedded 支持嵌入式虚拟化弹性底座,提供 Jailhouse 虚拟化方案、openAMP 轻量化混合部署方案,用户可以根据自己的使用场景选择最优的部署方案。同时支持 ROS humble 版本,集成 ros-core、ros-base、SLAM 等核心软件包,满足 ROS2 运行时要求。未来 openEuler Embedded 将协同 openEuler 社区生态伙伴、用户、开发者,逐步扩展支持 RISC-V、龙芯等芯片架构,丰富工业中间件、ROS 中间件、仿真系统等能力,打造嵌入式领域操作系统解决方案。

      • 南向生态: openEuler Embedded 22.03 LTS SP4当前主要支持 ARM64、x86-64 两种芯片架构,未来openEuler Embedded Linux还将支持龙芯、飞腾等芯片。
      • 嵌入式弹性虚拟化底座 :openEuler Embedded的弹性虚拟化底座是为了在多核片上系统(SoC, System On Chip)上实现多个操作系统共同运行的一系列技术的集合,包含了裸金属、嵌入式虚拟化、轻量级容器、LibOS、可信执行环境(TEE)、异构部署等多种实现形态。
      • 混合关键性部署框架: openEuler Embedded打造了构建在融合弹性底座之上混合关键性部署框架,并命名为MICA(MIxed CriticAlity),旨在通过一套统一的框架屏蔽下层弹性底座形态的不同,从而实现Linux和其他OS运行时便捷地混合部署。依托硬件上的多核能力使得通用的Linux和专用的实时操作系统有效互补,从而达到全系统兼具两者的特点,并能够灵活开发、灵活部署。
      • 北向生态:600+嵌入式领域常用软件包的构建;支持ROS2 humble版本,集成ros-core、ros-base、SLAM 等核心包,并提供软实时能力,软实时中断响应时延微秒级。
      • UniProton硬实时系统:是一款实时操作系统,具备极致的低时延和灵活的混合关键性部署特性,可以适用于工业控制场景,既支持微控制器 MCU,也支持算力强的多核 CPU。目前关键能力如下:
        • 支持Cortex-M、Arm64、x86_64架构,支持M4、RK3568、RK3588、x86_64、Hi3093、树莓派4B。
        • 支持树莓派4B、Hi3093、RK3588、x86_64设备上通过裸金属模式和openEuler Embedded Linux混合部署。
        • 支持通过gdb在openEuler Embedded Linux侧远程调试。
        • 支持890+ POSIX接口,支持文件系统、设备管理、shell控制台和网络。

      openEuler 内核新特性

      openEuler 22.03 LTS SP4 基于 Linux Kernel 5.10 构建,在此基础上,同时吸收了社区高版本的有益特性及社区创新特性。

      体系结构

      • 支持CPU在线巡检:静默数据损坏(SDC)可能导致数据丢失和数据被破坏。通过执行巡检指令,发现存在静默故障的核,提前对故障核进行隔离,避免出现更严重的故障,提高系统可靠性。

      • 自适应NUMA特性:随着摩尔定律放缓,硬件架构Scale-up的收益空间收窄,需要解决资源“locality”的问题,Scale-out是硬件架构的主要发展方向。对于NUMA架构而言,跨NUMA访存时延相比本地访存时延大大增加,而linux操作系统以吞吐为中心,强调负载均衡,打破全局跨NUMA访存最优的状态。本特性是以业务亲缘关系为中心的负载均衡机制:突破Linux调度模型中负载均衡的约束,以亲缘关系为中心,在资源未达到瓶颈时,将具有亲缘关系的任务packing在一起,减少跨NUMA访存。

        主要技术点包含如下:

        1. 感知亲缘关系:通过软硬协同,感知线程间网络、内存的亲缘关系。
        2. 感知资源瓶颈:基于NUMA维度的资源瓶颈感知,感知NUMA资源是否达到瓶颈。
        3. 优化选核和负载均衡机制:基于可编程调度的框架,突破linux原有负载均衡约束,决策NUMA内还是NUMA 间调度,在没有资源瓶颈前提下,将具有亲缘关系的任务调度到相同NUMA上。
      • xfs atomic write特性:数据库(如MySQL的InnoDB存储引擎)使用Doublewrite机制,写2次16KB数据到磁盘,来保护故障场景下数据不受部分写损坏的影响。xfs atomic write特性基于硬件的原子写能力,通过保证用户态软件发起的Direct IO原子性写入磁盘,可以替代数据库Doublewrite机制,以减少IO写数量,提升数据库的写入性能。

      • 增强核隔离特性:在HPC场景,由于每个线程会频繁进行同步,OS背景噪声对性能的影响会随着节点数增多逐步放大,OS背景噪声包括背景守护进程、外设中断、内核背景线程等。增强核隔离特性将系统CPU分为housekeeping CPU和non-housekeeping CPU,将OS背景噪声集中在housekeeping CPU上,non-housekeeping CPU只运行业务计算任务,通过减少业务运行时背景噪声的干扰,提升业务性能。

      non-housekeeping CPU可以通过启动参数nohz_full和isolcpus指定,增加enhanced_isolcpus参数后可以进一步消除磁盘IO的噪声干扰。详情可参考文档 kernel-parameters.txt

      调度

      支持功耗感知调度:在面向业务层面收集访存带宽,CPU负载等数据,确保业务关键线程资源得到满足。引入物理拓扑,调压域感知新的维度,减少单DIE调频、单DIE调压带来的调频降功耗的局限,保障在低负载下能最小化功耗。具体如下:

      1. 根据物理拓扑构建逃逸通道,根据CPU负载和访存带宽瓶颈自动调节节能级别,低负载集中业务减少功耗,高负载扩散业务的策略保证QOS。
      2. 定时器收集负载,带宽等信息,感知访存带宽,避免跨DIE访问。
      3. OS新增调压域、idle静态功耗感知、业务标签等机制,实现智能感知调频、CPU idle、DVFS,来优化业务性能。
      4. 提供一套任务标签化的机制来为每个用户态进程来标注自己的QoS等级,并且支持将标记为不同优先等级的任务分别绑定到不同的分区上进行调度,以此来保证业务QoS,每个QoS的功耗策略也可以通过cpufreq模块进行配置,以达到不影响业务QoS的前提下保障节能的需求。

      内存

      • cgroup粒度的KSM使能增强:通过memory.ksm接口为memcg中的进程使能KSM时,仅配置已在memcg中的进程,后续新加入memcg的进程不会自动使能KSM,需要重新调用该接口使能。该特性支持memcg的KSM状态位,向memory.ksm接口写入1后,新加入memcg的进程自动使能KSM,简化了为进程使能KSM的操作。
      • 支持地址随机化区域指定:内核增加CONFIG_NOKASLR_MEM_RANGE选项,允许用户指定至多4个物理内存区域,系统在启动时避开这4个内存区域进行物理地址随机化。arm64和x86_64架构的物理地址随机化支持从启动参数指定不随机化的范围,避免跟kdump预留内存冲突,解决内存多占用导致内存不足问题。
      • bufferio限速自动绑定memcg和blkcg:该特性由美团贡献到openEuler社区。当前,cgroup v1中的子系统独立,无法协同工作,如blkio cgroup在限制资源时无法感知memory cgroup中的资源使用,需手动创建映射关系。改进特性允许在内核态自动绑定同一进程的blkio cgroup和memory cgroup映射关系。用户可在编译阶段通过CONFIG_CGROUP_V1_BIND_BLKCG_MEMCG开关选择启用,也可在系统运行时通过sysctl_bind_memcg_blkcg_enable动态开关调整。

      虚拟化

      • KVM TDP MMU:该特性由Intel贡献到openEuler社区,是Linux 5.10之后,内存虚拟化领域中用于提升KVM可扩展性的一个改进方案。相对于传统的KVM MMU,TDP MMU提供了更高效的并发Page Fault处理机制,从而使得KVM对大型虚拟机(多vCPU,大内存)有了更好的支持。同时,通过采用新的EPT/NPT遍历接口,KVM TDP MMU摒弃了传统内存虚拟化中对rmap数据结构的依赖,使得主机内存有了更好的利用率。继openEuler 22.03-SP3中提供了Linux 5.10至5.15版本的KVM TDP MMU支持之后,openEuler 22.03-SP4版本增加了Linux 5.15至6.2版本间对KVM MMU的后续优化和bugfix,如提供优化大幅降低KVM MMU unloading的次数以及unloading的流程,优化KVM MMU page fault的处理流程,以及memslot更新时的相关优化等。
      • Dirty ring:该特性由麒麟软件贡献到openEuler社区。原始内核中对vcpu访问内存⻚的统计是通过dirty bitmap来实现的,dirty bitmap的统计粒度是⼀个kvm_mem_slot。而dirty ring的统计粒度更细,可以精确到⼀个vcpu甚⾄⼀个内存⻚,并且统计可以在⽤⼾空间进⾏,dirty ring的扩展性较好,可以在⼤内存规格的虚机上开启此特性。

      NestOS 容器操作系统

      NestOS是在openEuler社区孵化的云底座操作系统,集成了rpm-ostree支持、ignition配置等技术。采用双根文件系统、原子化更新的设计思路,使用nestos-assembler快速集成构建,并针对K8S、OpenStack等平台进行适配,优化容器运行底噪,使系统具备十分便捷的集群组建能力,可以更安全的运行大规模的容器化工作负载。

      1. 开箱即用的容器平台:NestOS集成适配了iSulad、Docker、Podman等主流容器引擎,为用户提供轻量级、定制化的云场景OS。
      2. 简单易用的配置过程:NestOS通过ignition技术,可以以相同的配置方便地完成大批量集群节点的安装配置工作。
      3. 安全可靠的包管理:NestOS使用rpm-ostree进行软件包管理,搭配openEuler软件包源,确保原子化更新的安全稳定状态。
      4. 友好可控的更新机制:NestOS使用zincati提供自动更新服务,可实现节点自动更新与重新引导,实现集群节点有序升级而服务不中断。
      5. 紧密配合的双根文件系统:NestOS采用双根文件系统的设计实现主备切换,确保NestOS运行期间的完整性与安全性。

      机密计算远程证明服务:远程证明TEE插件框架

      随着机密计算的逐渐成熟,机密计算硬件众多,信任根及远程证明差异,成为阻塞TEE之间建立信任关系的关键,构建远程证明统一框架,提供证明代理、TEE插件框架等组件,实现不同TEE证明报告统一验证流程。

      • 当前版本证明代理支持鲲鹏Trustzone、virtCCA证明报告获取。
      • TEE报告校验插件框架支持运行时兼容鲲鹏Trustzone、virtCCA证明报告验证,并支持证明代理集成TEE报告校验插件框架,实现无证明服务时的点对点验证。

      DPU 场景 vDPA 新增支持磁盘,并支持配置vDPA网卡和磁盘的虚机热迁移

      内核态vDPA框架,为设备虚拟化提供了一种性能与直通持平,且支持跨硬件厂商热迁移的方案。新增对于DPU卡形态的硬件支持,支持DPU卡呈现给前端主机的网络/存储设备,接入通用vDPA框架,并支持热迁移。

      DPU场景vDPA需求继承openEuler 2203 LTS SP1/SP3支持vDPA网卡设备以及支持vDPA网卡直通热迁移特性。新增支持对于DPU卡形态呈现存储设备的支持,并继承支持vDPA磁盘直通热迁移特性。详细范围说明如下:

      • 支持虚拟机配置vDPA磁盘作为数据盘。
      • 支持虚拟机热插拔vDPA磁盘。
      • 支持同时配置vDPA网卡和vDPA磁盘热迁移。

      virtCCA 机密虚机特性合入

      virtCCA机密虚机特性在TEE侧实现机密虚机能力,实现现有普通虚机中的软件栈无缝迁移到机密环境中。

      基于Arm CCA标准接口,在Trustzone固件基础上构建TEE虚拟化管理模块,实现机密虚机间的内存隔离、上下文管理、生命周期管理和页表管理等机制,支持客户应用无缝迁移到机密计算环境中。

      技术约束:

      1. 机密虚机每次启动需要对Guest Kernel等内存信息进行度量,因此不支持reboot能力.
      2. 基于安全性考虑,宿主机BIOS中CPU超线程需要关闭。

      PowerAPI 功耗管理统一API

      PowerAPI是一组用于支持系统功率管理的 API,它们提供了一种标准化方法来管理系统的功率使用情况,包括监控,调整和优化系统的功率消耗。这些 API 可以帮助系统管理员更好地管理系统的能源消耗,从而提升系统的效率和可靠性,并减少能源成本。

      PowerAPI含pwrapis服务程序和libpwrapi.so动态库。PowerAPI实际上是对OS提供的各类接口的统一封装,方便上层管理软件对功耗进行统一管理,其目标为:

      • 屏蔽底层sci/sysfs/procs/impi等接口差异,屏蔽平台差异。
      • 屏蔽功耗管理场景下,root特权需求(如集群代理Agent不要求采用root用户运行)。

      PowerAPI接口已提供功能:

      • 数据采集:系统功耗、CPU利用率、LLC cache Miss等。
      • CPU调频、CPU休眠管理。
      • 瓦特调度管理、分域调度管理 。

      eagle 实现整机能耗管理

      Eagle(Energy Aware intelliGent scheduler)智能功耗感知调节器是一个以提升能效为目标的调优服务。用户可通过配置策略的方式,让eagle实现整机功耗管理,进而提升能效,实现降本增效。Eagle基于PowerAPI构建,实现基于策略的能效调优。

      1. 调优策略:用户可根据业务情况,定制调优策略。
      2. 智能场景感知功耗调节:eagle通过powerapi实时感知并结合场景特点(CPU密集/访存密集/时延敏感),应用优先级,通过智能调度、调频、Turbo、休眠等调节手段,保证业务体验的前提下,自适应地实现能效最优。
        • 基于能效域的智能调度:通过划分能效域,按需激活资源、均衡调度、智能Turbo等实现能效最优。
        • 性能损失可控的调频:通过实时感知业务性能变化,严格控制CPU调频导致的性能下降。
        • 更精确的智能休眠:实时感知业务特点,制定更适合业务的CPU、外设休眠策略。
        • 多维度功耗封顶控制:在功耗限额下,通过多维度、多设备的控制,保证高优先级应用的前提下,实现能效最优。
        • 基于预测的风扇调速: 通过建模,智能预测整机热变化,风扇提前响应,提升整机热可靠性,节省能耗。
      3. 人机交互:管理员可通过eagle-CLI实时监控系统状态,或对调优策略等进行配置。

      gala-ragdoll 支持配置变更溯源

      利用ragdoll内部插件ragdoll-filetrace可以实现对配置文件的实时监控,当配置文件被修改的时候,会抓取操作文件的系统调用的信息保存到mysql数据库表中,ragdoll通过接口形式将数据库的数据提供给aops-hermes,用户可以在页面端查看配置文件的变更信息,比如:修改时间,修改方式,进程名称。目前可以支持监控系统中常用文本编辑工具,比如vi/vim、sed、echo、mv等。

      文档捉虫

      “有虫”文档片段

      问题描述

      提交类型 issue

      有点复杂...

      找人问问吧。

      PR

      小问题,全程线上修改...

      一键搞定!

      问题类型
      规范和低错类

      ● 错别字或拼写错误;标点符号使用错误;

      ● 链接错误、空单元格、格式错误;

      ● 英文中包含中文字符;

      ● 界面和描述不一致,但不影响操作;

      ● 表述不通顺,但不影响理解;

      ● 版本号不匹配:如软件包名称、界面版本号;

      易用性

      ● 关键步骤错误或缺失,无法指导用户完成任务;

      ● 缺少必要的前提条件、注意事项等;

      ● 图形、表格、文字等晦涩难懂;

      ● 逻辑不清晰,该分类、分项、分步骤的没有给出;

      正确性

      ● 技术原理、功能、规格等描述和软件不一致,存在错误;

      ● 原理图、架构图等存在错误;

      ● 命令、命令参数等错误;

      ● 代码片段错误;

      ● 命令无法完成对应功能;

      ● 界面错误,无法指导操作;

      风险提示

      ● 对重要数据或系统存在风险的操作,缺少安全提示;

      内容合规

      ● 违反法律法规,涉及政治、领土主权等敏感词;

      ● 内容侵权;

      您对文档的总体满意度

      非常不满意
      非常满意
      提交
      根据您的反馈,会自动生成issue模板。您只需点击按钮,创建issue即可。
      文档捉虫
      编组 3备份