首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

linux的一个进程调度周期内新加入进程的处理机制分析

最近在研究Linux的短程调度(进程调度包括长程调度、中程调度和短程调度,详见参考博客1)相关的算法和调度器,由参考博客1可知,短程调度的主要任务是按照某种策略和算法将处理机分配给一个处于就绪状态的进程,分为抢占式和非抢占式。中程调度(又叫中级调度)的主要任务则是按照给定的原则和策略,将处于外存交换区中的就绪状态或等待状态的进程调入内存,或把处于内存就绪状态或内存等待状态的进程交换到外存交换区。长程调度(又叫高级调度)的主要任务则是将已进入系统并处于后备状态的作业按某种算法选择一个或一批,为其建立进程,并进入主机,装入内存;当该作业执行完毕时,负责回收系统资源。如下图所示:

03
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    dpdk 性能_第二系列什么意思

    首先,DPDK和内核网络协议栈不是对等的概念。 DPDK只是单纯的从驱动拿数据,然后组织成数据块给人用,跑在用户态。功能相当于linux的设备无关接口层,处于socket之下,驱动之上。只不过linux协议栈的这部分在核心态。 你说的包处理器,很多时候是不用linux内核协议栈的,而是用专用包处理程序,类似于DPDK加上层应用处理。通常会有些硬件加速器,包处理效率更高些。缺点是一旦用不上某些功能,那些加速器就白费了。而纯软件处理就非常灵活,不过代价就是功耗和性能。 纯DPDK性能非常高,intel自己给出的数据是,处理一个包80时钟周期。一个3.6Ghz的单核双线程至强,64字节小包,纯转发能力超过90Mpps,也就是每秒9千万包。 不知你有没有看出来,80周期是一个非常惊人的数字?正常情况下,处理器访问一下ddr3内存都需要200个周期,而包处理程序所需要操作的数据,是从pcie设备送到ddr内存的,然后再由处理器读出来,也就是说,通常至少需要200周期。为啥现在80周期就能完成所有处理?我查了下文档,发现原因是使用了stashing或者叫direct cache access技术,对于PCIe网卡发过来的包,会存在一个特殊字段。x86的pcie控制器看到这个字段后,会把包头自动塞到处理器的缓存,无序处理器来干预。由于包头肯定是会被读取的,这样相当于提前预测,访问的时间大大缩短。 如果加上linux socket协议栈,比如跑个纯http包反弹,那么根据我的测量,会掉到3000-4000周期处理一个包,单核双线程在2.4Mpps,每秒两百四十万包,性能差40倍。 性能高在哪?关键一点,DPDK并没有做socket层的协议处理,当然快。其他的,主要是使用轮询替代中断,还有避免核心态到用户态拷贝,并绑定核,避免线程切换开销,还有避免进入系统调用的开销,使用巨页等。 还有很关键的一点,当线程数大于12的时候,使用linux协议栈会遇到互斥的瓶颈,用性能工具看的话,你会发现大部分的时间消耗在spin_lock上。解决方法之一是如github上面的fastsocket,改写内核协议栈,使包始终在一个核上处理,避免竞争等。缺点是需要经常自己改协议栈,且应用程序兼容性不够。 另外一个方法是使用虚拟机,每个特征流只在一个核处理,并用虚拟机隔绝竞争,底层用dpdk做转发,上层用虚拟机做包处理,这样保证了原生的linux协议栈被调用,做到完全兼容应用程序。不过这种方法好像还没有人做成开源的,最近似的是dpdk+虚拟交换机ovs的一个项目。 如果你只想要dpdk的高性能加tcp/ip/udp的处理,不考虑兼容性,那么还可以去买商业代码,我看了下供应商的网站介绍,纯转发性能大概在500-1000周期左右一个包。

    01

    郭健: deadline调度器之(一):原理

    实时系统是这样的一种计算系统:当事件发生后,它必须在确定的时间范围内做出响应。在实时系统中,产生正确的结果不仅依赖于系统正确的逻辑动作,而且依赖于逻辑动作的时序。换句话说,当系统收到某个请求,会做出相应的动作以响应该请求,想要保证正确地响应该请求,一方面逻辑结果要正确,更重要的是需要在最后期限(deadline)内作出响应。如果系统未能在最后期限内进行响应,那么该系统就会产生错误或者缺陷。在多任务操作系统中(如Linux),实时调度器(realtime scheduler)负责协调实时任务对CPU的访问,以确保系统中的所有的实时任务在其deadline内完成。

    02

    郭健:deadline调度器之(一):原理

    实时系统是这样的一种计算系统:当事件发生后,它必须在确定的时间范围内做出响应。在实时系统中,产生正确的结果不仅依赖于系统正确的逻辑动作,而且依赖于逻辑动作的时序。换句话说,当系统收到某个请求,会做出相应的动作以响应该请求,想要保证正确地响应该请求,一方面逻辑结果要正确,更重要的是需要在最后期限(deadline)内作出响应。如果系统未能在最后期限内进行响应,那么该系统就会产生错误或者缺陷。在多任务操作系统中(如Linux),实时调度器(realtime scheduler)负责协调实时任务对CPU的访问,以确保系统中的所有的实时任务在其deadline内完成。

    02

    The Linux Scheduler: a Decade of Wasted Cores 译文 一

    ​ 作为资源管理的核心部分,OS的线程调度器必须保持下面这样简单,不变的特性: 确保ready状态的线程总是被调度到有效的CPU核上。虽然它看起来是简单的,我们发现这个不变性在Linux上经常被打破。当ready状态的线程在runqueue中等待时,有些CPU核却还会空闲几秒。以我们的经验,这类性能方面的问题会导致重度依赖同步的应用的性能成倍的下降,针对Kernel编译会多造成高达13%的延迟,针对广泛使用的商用数据库会造成23%的吞吐量降低。传统的测试技术和调试工具对于确认和了解这类问题是无效的,因此这些问题的症状经常是难以捕获的。为了能够推动我们的调查,我们构建了新的工具来在线检测这种违反不变性的情况并且将调度行为可视化。这些工具是简单的,易于在多个kernel版本间移植的并且使用的代价很小。我们相信这些工具将成为内核开发者工具链的一部分来帮助其避免这类问题的出现。

    01
    领券