我有一个 Linux 系统，我们使用 cgroups 创建了两个 cpu_exclusive cpuset，A 和 B，并且我们将所有用户线程和所有未绑定的内核线程迁移到附加到 cpuset A 的 cgroup。在 cpuset A 中运行的事物具有不同的调度程序策略和不同的优先级，并且 cpuset A 中运行的线程比 cpuset A 中的内核数多得多。
还有一些非常活跃的进程附加到 cpuset B 上，这些进程中的用户线程总数永远不会大于 cpuset B 中专门可用的内核数。 目标是屏蔽这些在 cpuset 中运行的重要任务B 来自机器上的其他活动并最大限度地减少处理延迟。
在这样的设置中，在 cpuset B 中运行的用户线程的调度策略/优先级是否有任何可观察到的影响？换种说法：将 B cpuset 线程的调度策略从默认的 SCHED_OTHER 更改为 SCHED_FIFO 或 SCHED_RR 会有什么后果，好还是坏？
似乎答案应该是“否”，因为调度程序应该能够为在 cpuset B 中运行的每个线程分配其自己的专用内核，因此不会有任何优先级或调度，因此 B 的策略和相对优先级cpuset 线程无关紧要。另一方面，需要担心绑定的内核线程和“调度程序域”方面，可能还有其他我没有考虑过的事情。
在任何实际意义上，在过度配置的独占 cpuset 中运行的线程的调度策略和优先级是否重要？
我需要 Ubuntu 12.04 上存在 cs_CZ.ISO8859-2 语言环境，以便特定的单元测试可以通过。该测试进行以下调用：
std::locale("cs_CZ.ISO8859-2")
在我安装的 OS X Lion 上，该语言环境确实存在，因此对 std::locale 的调用应该有效：
$ locale -a | grep cs
cs_CZ
cs_CZ.ISO8859-2
cs_CZ.UTF-8
$
然而，在我安装的 Ubuntu 12.04 上，尽管已安装，但只有 UTF8 变体，并且没有 ISO8859-2 版本的 cs_CZ 语言环境language-pack-cs：
$ dpkg -l | grep language-pack-cs
ii language-pack-cs 1:12.04+20120417 translation updates for language Czech
ii language-pack-cs-base 1:12.04+20120417 translations for language Czech
$ locale -a | grep cs_
cs_CZ.utf8
$
在这台机器上单元测试失败。在 strace 下运行单元测试表明它确实在寻找 ISO8859-2 变体，但在任何地方都找不到它：
open("/usr/lib/locale/cs_CZ.ISO8859-2/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) …