我正在运行一个进程(在基于Linux 3.x的 *** 作系统上),其中:
>一些线程是’管理器’线程(为简单起见,假设他们决定哪些工作线程应该做什么,但不做任何I / O,并且他们需要的cpu时间总共短于/短于工人线程’)
>更多的线程是’工人’线程:他们在计算方面做了很多提升,我在任何时候被抢先都没有问题.
可能存在超额预订(即,使用HT的英特尔处理器上的工作线程数超过核心的两倍).现在,我看到的是’经理’线程没有足够频繁地获得处理器时间.他们并非完全’挨饿’,我只是想给他们一个提升.所以,我自然而然地想到设置不同的线程优先级(我在linux上) – 但后来我注意到线程调度程序的不同选择及其效果.此时我感到困惑,或者更确切地说 – 我不清楚:
>我应该为经理选择哪种调度策略,为工人选择哪种调度策略?
>我应该将线程优先级设置为什么(如果有的话)?
>我是否需要偶尔让我的线程屈服()?
笔记:
>我故意不再谈论语言或线程池机制.我想在更一般的环境中提出这个问题.
>请不要对cpu核心做出假设.可能有很多,或者可能只有一个,也许我需要每个核心上的工人(或工人和经理).
>工作线程可能会也可能不会执行I / O.但是,对于他们没有做任何I / O的情况的答案是受欢迎的.
>除了运行我的应用程序之外,我真的不需要系统非常灵敏.我的意思是,我宁愿能够在那里使用SSH,让我的打字回复给我,没有明显的延迟,但没有真正的限制.最佳答案UPD 12.02.2015:我做了一些实验.
理论
将“管理器”线程调度程序更改为RT(提供SCHED_DEADliNE / SCHED_FIFO策略的实时调度程序)有明显的解决方案.在这种情况下,“管理器”线程将始终具有比系统中大多数线程更大的优先级,因此它们几乎总是在需要时获得cpu.
但是,还有另一种解决方案可以让您继续使用CFS调度程序.您对“工人”线程的目的描述与批处理调度类似(在古代,当计算机很大时,用户必须将他的工作放到队列中并等待数小时才能完成). linux CFS通过SCHED_BNCH策略和对话作业通过SCHED_norMAL策略支持批处理作业.
内核代码(kernel/sched/fair.c)中也有用的注释:
/* * Batch and IDle tasks do not preempt non-IDle tasks (their preemption * is driven by the tick): */if (unlikely(p->policy != SCHED_norMAL) || !sched_feat(WAKEUP_PREEMPTION)) return;
因此,当“管理器”线程或其他事件唤醒“工作者”时,后者只有在系统中有空闲cpu或“管理器”耗尽其时间片(调整它改变任务的权重)时才会获得cpu.
如果不更改调度程序策略,似乎无法解决您的问题.如果“工人”线程很忙并且“经理”很少醒来,他们会得到相同的vruntime奖金,所以“工人”总是会抢占“经理”线程(但你可能会增加他们的体重,所以他们会更快地耗尽他们的奖金).
实验
我有一台带有2个Intel Xeon E5-2420 cpu的服务器,它为我们提供了24个硬件线程.为了模拟两个线程池,我使用了自己的TSLoad工作负载生成器(并在运行实验时修复了几个错误:)).
有两个线程池:具有4个线程的tp_manager和具有30个线程的tp_worker,两者都运行busy_wait工作负载(仅用于(i = 0; i 3.12(带调试配置的vanilla) 3.2(股票Debian) 一些说明: >所有时间都以毫秒为单位 以上是内存溢出为你收集整理的c – 如何为流程的“经理”和“工人”线程划分优先级(或设置调度策略)?全部内容,希望文章能够帮你解决c – 如何为流程的“经理”和“工人”线程划分优先级(或设置调度策略)?所遇到的程序开发问题。 如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。 欢迎分享,转载请注明来源:内存溢出EXP | MANAGER | WORKER | sched wait service | sched service | policy time time | policy time33 | norMAL 0.045 2.620 | WAS NOT RUNNING34 | norMAL 0.131 4.007 | norMAL 125.19235 | norMAL 0.123 4.007 | BATCH 125.14336 | norMAL 0.026 4.007 | BATCH (nice=10) 125.29637 | norMAL 0.025 3.978 | BATCH (nice=19) 125.22338 | FIFO (prio=9) -0.022 3.991 | norMAL 125.18739 | core:0:0 0.037 2.929 | !core:0:0 136.719
EXP | MANAGER | WORKER | sched wait service | sched service | policy time time | policy time46 | norMAL 0.032 2.589 | WAS NOT RUNNING45 | norMAL 0.081 4.001 | norMAL 125.14047 | norMAL 0.048 3.998 | BATCH 125.20550 | norMAL 0.023 3.994 | BATCH (nice=10) 125.20248 | norMAL 0.033 3.996 | BATCH (nice=19) 125.22342 | FIFO (prio=9) -0.008 4.016 | norMAL 125.11039 | core:0:0 0.035 2.930 | !core:0:0 135.990
>最后一个实验用于设置亲和力(由@PhilippClaßen建议):经理线程绑定到Core#0,而工作线程绑定到除Core#0之外的所有核心.
>管理器线程的服务时间增加了两倍,这可以通过内核内的并发来解释(处理器具有超线程!)
>使用SCHED_BATCH不错(TSLoad不能直接设置权重,但很好的可以间接设置)稍微减少等待时间.
> SCHED_FIFO实验中的负等待时间是可以的:TSLoad保留30us所以它可以做初步工作/调度程序有时间进行上下文切换/等等.看起来SCHED_FIFO非常快.
>保留单核并不是那么糟糕,因为它消除了核心内并发性,服务时间显着减少 总结
评论列表(0条)