完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
电子发烧友论坛|
简介
上个世纪，研发人员投入了大量精力提高Linux实时性能和行为，最著名的是PREEMPT_RT Linux实时扩展。最近，研发人员致力于研究适用于多核设备的Linux用户空间解决方案，该解决方案允许从用户空间中直接访问基础硬件，从而可避免因将Linux内核引入用户空间应用而带来的额外系统开销。这些用户空间扩展（有多个）已首先由电信/网络高性能 IP 数据包处理系统进行驱动，以实现所谓的“裸金属”实施，其中，多核设备中的Linux用户空间应用可以模拟“无操作系统”解决方案的执行过程，即在每个内核上进行简单“运行到完成”、轮询循环，以便进行数据包处理。在从根本上实现该目标的同时，该解决方案仍可用于非常特殊的用例。还有其他需要提高性能的用例无法通过以上解决方案完全解决吗？如果有的话，请列举出来，是否可应用更完善的Linux实时改进？答案是肯定的，采用Linux用户空间轻型线程 (light-weight threading, LWT) 即可。我们来研究一下实时 Linux，以及轻型线程如何能成为适用于某些应用的解决方案。研究的重点受电信、网络或常用通信应用的影响，Enea侧重于这些应用中采用的技术。但总体上来说，对轻型线程的重点应用会使多方受益。 
0
|
|
相关推荐
4个回答
|
|
|
实时Linux及其解决的问题
在过去的10 年中，Linux 已在实时性能和行为方面取得了显著的进步，满足了大量应用的需求。具体归纳如下： PREEMPT_RT PREEMPT_RT也许是Linux实时扩展取得的最显著的成就，PREEMPT_RT数据包解决了多核设备Linux中存在的特别棘手的问题，即“中断延迟”问题。将事件/数据传送到真实用户空间应用之前，处理Linux内核中的中断占用的系统开销非常高 - 该系统开销往往会延迟其他中断，从而增大发生中断时测得的中断信息接收方进行处理的总体延迟。同样，Linux内核中还有许多所谓的“重要部分”，可在其中通过自旋锁禁用中断。标准Linux内核的总体中断延迟与许多实时应用的最重要的中断延迟要求不符，特别是无线接入网（移动）和移动核心基础设施，这两者要求最差情况下的中断延迟应在20-30微秒范围内。这一点也适用于许多其他市场应用。在快速“nutshell”PREEMPT_RT中，这一问题是通过以下方式解决的： ●将全部设备驱动器中断句柄传递到可调度线程中，这样可最大程度地减少Linux内核对中断的处理工作，因此，无需等待前一中断处理完成便可处理新中断。之后，中断处理会变为受优先级驱动，根据用户需求，会先完成优先级最高的中断处理。 ●将Linux内核中的所有死空间自旋锁传递到互斥量中，从而允许其他内核线程代替内核空间自旋锁运行。 基本上，PREEMPT_RT已根据非常高性能的实时标准将总体中断延迟成功缩短，这样对大量Linux应用都非常有帮助。要了解具体应用？请继续往下读。 用户空间Linux调整 如上文所述，近年来，研发人员对Linux用户空间应用投入了大量精力。目的是避免用户空间应用（Linux 用户对其附加价值投入了大量精力）占用Linux内核本身的系统开销来处理某些特定的设备/中断交互。Linux采用的模型可极大程度地防止用户空间应用受到内核的影响，在该模型中，所有用户空间操作（包括线程）始终会映射到Linux内核，以便处理其I/O请求。这样便Linux具有强大的行为和特性。但是，对于数据处理性能非常高的应用来说，即使采用PREEMPT_RT，Linux也会有短时故障，这是因为，总是需要进行Linux内核上下文切换才能直接访问硬件。用户空间Linux实施允许应用在不涉及Linux内核的情况下直接访问硬件和中断，并可极大程度地提高性能。但这种性能提升只能在I/O密度极高的环境中实现。大部分Linux用户空间调整都侧重于单线程应用（如高性能数据包处理），其中，Linux下只有一个线程用于模拟多核设备中的“无操作系统”性能。 |
|
|
|
|
|
多线程问题
实时Linux解决方案调查中缺少的是认真检查多线程在实时嵌入式应用中的有效性。实际上，早在20世纪80年代Linux出现之前，人们就提出了需要采用嵌入式实时操作系统(RTOS) 来实现低延迟、高吞吐量、极具实时特点的应用。操作系统的结构发生了变化，但对这方面的需求却没有改变。此类RTOS解决方案所具有的各种性能、行为和特性是过去十多年中Linux一直尝试达到的。这并不意味着倾向于恢复使用RTOS，而是要达到RTOS所具有的功能。就便携性、应用的广阔生态系统以及设备支持和常规支持来讲，Linux在实时嵌入式解决方案中的总体价值是任何RTOS都无法比拟的。存在两个实际问题： ●多线程为何重要？ ●如果多线程很重要，那么我们应如何将RTOS多线程性能、行为和特性添加到Linux中，以便取得更大的成功？关键问题是了解Linux多线程实施与RTOS，然后考虑可以进行哪些改进。 多线程为何重要？ 30多年前，当计算机解决方案软件设计人员碰到单线程解决方案无法解决的复杂问题时，便已提出了对多线程实时性方面的需求。所需解决方案要求单个应用具有多个任务，也许一些是计算任务，一些是受I/O驱动的任务，但是，就任务的总体执行而言，所有任务均密切相关。但多个任务密切相关意味着这些任务应共享一部分CPU时间才能达到CPU的有效总体利用率。在很多此类应用中，必须禁止执行某些操作、等待某些I/O事件或另一应用发出的其他通信。因此出现了简单的可执行程序，这些可执行程序可以处理多个线程，同时可禁用线程，并可在各线程之间进行低延迟通信。 并非所有实时应用都需要支持重要的多线程处理功能。本文并未对相关应用进行分类。但很显然，需要使用多线程处理功能的应用是那些需要在协议中设定“等待状态”的任何类型的复杂协议，即等待允许应用继续进行的响应或事件。之后，应用应放弃对CPU的控制权，允许运行其他类似的线程，来代替该响应或事件。 也许上述教程对于许多人来说很简单。请注意，很多移动基础设施和核心网络设备供应商得出的结论是，虽然Linux是当前或未来系统的首选，但目前构建的Linux还不足以满足业界的全部要求。原因是什么？ |
|
|
|
|
|
采用PTHREADS的Linux多线程
Pthreads是由IEEE规划的可移植操作系统接口(POSIX)创建的，目的是为了解决Unix中存在的高性能、多线程问题，之后被Linux用在最早的版本中，用于为企业实施可移植Unix，目前用于嵌入式应用中。 创建pthreads模型是为了解决原始Unix Fork/Join模型创建Unix“子”进程时出现的问题。由于该模型涉及到创建（还可能涉及删除）整个受内存保护的环境及执行模式，因此Unix进程模型非常庞大。需要在Unix下采用适用于多线程的较轻型模型，因此pthreads应运而生。 但Unix（也包括Linux）模型是专为将内核与用户空间应用完全分离而设计的，其优势之一在于提供的保护、安全性和可靠性远胜于其他实施方案（包括过去10几年间使用的RTOS）。实质上，这意味着Linux用户空间中的每个pthread都会由Linux内核线程表示，因此，全部或大部分Linux系统调用（特别是设备驱动器）均可通过用户空间进行访问。但是，由于OEM制造的产品并不具备GPL，因此用户空间中实际存储了所有嵌入式Linux实时应用。因此，在每种情况下，使用pthreads都涉及到调用Linux内核，从而为本可以在本地实施的应用带来了额外的系统开销。 但请您稍稍考虑一下。采用上文提到的Linux实时扩展怎么样？是的，PREEMPT_RT可以解决Linux内核中存在的许多关于响应性的问题，但不能真正解决多线程问题。实施用户空间 Linux可解决设备驱动器/中断性能问题，但并不能真正解决多线程问题。Linux实时容器可解决部分问题，但实时容器只是一种基于标准Linux的用户空间Linux可视化技术，并不能真正解决根本的多线程问题。 |
|
|
|
|
|
轻型线程(LWT)——复杂Linux应用的真正解决方案
之前针对Linux提出了多种轻型线程模型的建议，但没有一种模型能够真正解决问题。原因何在？因为大多数模型的功能都不是很强大。涉及复杂多线程应用的下一代Linux解决方案真正需要的是适用于用户空间Linux应用的全新Linux模型。下文概括介绍了这种名为Linux轻型线程(LWT)的解决方案。将高性能、低系统开销、多线程调度器植入Linux用户空间，来代替单独的pthread。原因何在？ ●Pthread系统开销 ●进程和pthreads是Linux了解的唯一调度实体。 ●LWT pthread只是一个Linux编码执行背景，可用于永久运行pthread。由于用户空间调度器始终保持控制，因此pthread绝不会被挂起，省电模式除外。这种情况不在本文的讨论范围。 该用户空间调度器的运行和操作方式与某些传统RTOS高性能、低延迟实施完全相同，但不会涉及到Linux内核。 实施过程利用新用户空间Linux实施过程来直接访问硬件。同样也不涉及Linux内核。 上述LWT解决方案可在任何Linux实时应用中实现动态性能的提升。Enea已设计出上述LWT的一些原型，事实证明，与Linux pthreads在调度器系统开销、特别是上下文切换和线程间消息发送/通信延迟方面的性能相比，LWT性能可提高10倍。 但是除了调度性能和线程间通信功能之外，LWT解决方案还应带来什么？LWT概念除了在性能方面胜过Linux pthreads之外，还有更多优势。解决方案稳健性的概念如何？与历史悠久的RTOS实时解决方案一样，LWT也需要具有以下额外Linux特性： ●决定性调度 ●调度系统开销低——上下文切换成本低 ●线程间信号系统开销低 ●线程创建成本低 |
|
|
|
|
只有小组成员才能发言，加入小组>>
791 浏览 0 评论
1151 浏览 1 评论
2527 浏览 5 评论
2860 浏览 9 评论
移植了freeRTOS到STMf103之后显示没有定义的原因？
2710 浏览 6 评论
keil5中manage run-time environment怎么是灰色，不可以操作吗？
1070浏览 3评论
193浏览 2评论
455浏览 2评论
368浏览 2评论
M0518 PWM的电压输出只有2V左右，没有3.3V是怎么回事？
453浏览 1评论
/6 
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
1674
评论
淘帖
1059
