/openbmc/linux/Documentation/translations/zh_CN/scheduler/ |
H A D | sched-capacity.rst | 18 1. CPU算力 24 一般来说,同构的SMP平台由完全相同的CPU构成。异构的平台则由性能特征不同的CPU构成,在这样的 27 我们引入CPU算力(capacity)的概念来测量每个CPU能达到的性能,它的值相对系统中性能最强的CPU 28 做过归一化处理。异构系统也被称为非对称CPU算力系统,因为它们由不同算力的CPU组成。 90 具有不同算力值的CPU,通常来说最大操作性能值也不同。考虑上一小节提到的CPU(也就是说, 169 CPU算力与任务利用率具有类型的效应,在算力不同的CPU上执行完全相同的工作负载,将算出不同的 255 完整包含某个CPU算力值的全部CPU。 305 任务将要更长地消耗该CPU,任务是CPU受限的(CPU-bound)。 316 条件的CPU:: 372 实时任务唤醒时的CPU选择,搜索满足以下条件的CPU:: [all …]
|
H A D | sched-stats.rst | 25 CPU上仲裁平衡,而domain0是最紧密聚焦的域,有时仅在一对CPU之间进行平衡。此时, 27 CPU受该域的影响。 38 CPU统计数据 56 6) 调用try_to_wake_up()导致本地CPU被唤醒了#次 62 9) 本CPU运行了#个时间片 67 对于每个被描述的CPU,和它相关的每一个调度域均会产生下面一行数据(注意,如果 72 第一个字段是一个位掩码,表明该域在操作哪些CPU。 139 和上次运行不同的新CPU上运行了#次 141 的CPU次数为#,因为该任务在原CPU是冷缓存状态 149 1) 在CPU上运行花费的时间(单位是纳秒) [all …]
|
H A D | sched-domains.rst | 23 超集(如有需求出现,这个限制可以放宽)。CPU i的基调度域必须至少管辖CPU i。每个CPU的 24 顶层调度域通常将会管辖系统中的全部CPU,尽管严格来说这不是必须的,假如是这样,会导致某些 25 CPU出现永远不会被指定任务运行的情况,直到允许的CPU掩码被显式设定。调度域的span字段意味 26 着“在这些CPU中做进程负载均衡”。 30 指针指向的这些组包含的CPU,必须被调度域管辖。组包含的是只读数据,被创建之后,可能被多个 31 CPU共享。任意两个组的CPU掩码的交集不一定为空,如果是这种情况,对应调度域的SD_OVERLAP 32 标志位被设置,它管辖的调度组可能不能在多个CPU中共享。 35 管辖的每个CPU的负载之和。仅当组的负载不均衡后,任务才在组之间发生迁移。 48 的运行队列中找出最繁忙的运行队列。如能找到,对当前的CPU运行队列和新找到的最繁忙运行 56 CPU的全部虚拟CPU,每个虚拟CPU对应一个调度组。 [all …]
|
H A D | sched-energy.rst | 61 CPU中挑选一个经预测能量消耗最优的CPU。EAS的预测依赖于对平台拓扑结构特定元素 72 任务/CPU有多大/有多忙,并在评估性能与能量时将其考虑在内。CPU算力由特定体系 116 来做任务放置决定。这个函数寻找在每个性能域中寻找具有最高剩余算力(CPU算力 - CPU 117 利用率)的CPU,因为它能让我们保持最低的频率。然后,该函数检查将任务放在新CPU相较 134 目前CPU的利用率情况如下图所示。CPU 0-3的util_avg分别为400、100、600和500。 138 CPU util. 238 从一般的角度来看,EAS能提供最大帮助的是那些涉及低、中CPU利用率的使用场景。每当CPU 242 EAS很可能将负载放置在系统中能量效率最高的CPU而不是其它CPU上,只要不损害吞吐率。 268 6.1 - 非对称CPU拓扑 325 这一点,它假定CPU的OPP跟随CPU利用率变化而变化。 [all …]
|
H A D | schedutil.rst | 22 通过PELT,我们跟踪了各种调度器实体的一些指标,从单个任务到任务组分片到CPU 36 请注意,阻塞态的任务仍然对累加值(任务组分片和CPU运行队列)有贡献,这反映了 40 在CPU上花费的时间,而“可运行”反映了一个调度实体在运行队列中花费的时间。当只有 42 任务在CPU上花费的时间,而“可运行”将增加以反映争用的激烈程度。 47 频率 / CPU不变性 50 因为CPU频率在1GHz时利用率为50%和CPU频率在2GHz时利用率为50%是不一样的,同样 78 r_cpu被定义为当前CPU的最高性能水平与系统中任何其它CPU的最高性能水平的比率。 83 我们可以在CPU之间转移和比较它们。 126 其基础是CPU运行队列的“运行”指标,根据上面的内容,它是CPU的频率不变的利用率 159 CPU,有4个任务占用导致其饱和,接下来我们将一个任务迁移到另一个空闲CPU上, [all …]
|
/openbmc/linux/Documentation/translations/zh_CN/core-api/ |
H A D | cpu_hotplug.rst | 35 以保持一个不需要的CPU不在系统执行路径。因此需要在Linux内核中支持CPU热拔插。 49 限制内核将支持的CPU总量。如果这里提供的数量低于实际可用的CPU数量,那么其他CPU 68 CPU位图 129 CPU又可以使用了。这应该对所有的CPU都有效。CPU0通常比较特殊,被排除在CPU热拔插之外。 149 * 所有进程都会从这个将要离线的CPU迁移到新的CPU上。新的CPU是从每个进程的当前cpuset中 152 * 所有针对这个CPU的中断都被迁移到新的CPU上。 183 在该阶段中,startup回调在CPU上线操作启动CPU之前被调用,teardown回调在CPU下线操作使 186 这些回调是在控制CPU上调用的,因为它们显然不能在热插拔的CPU上运行,此时热插拔的CPU要 202 插的CPU上被调用。teardown回调是在CPU完全关闭前不久的CPU下线操作期间,禁用中断的情况 213 该阶段中的startup回调是在CPU上线时在热插拔的CPU上调用的。teardown回调是在CPU下线操 [all …]
|
H A D | this_cpu_ops.rst | 25 this_cpu操作将每CPU变量的偏移量添加到处理器特定的每CPU基址上,并将该操作编码到对 66 在x86上,fs:或gs:段寄存器包含每CPU区域的基址。这样就可以简单地使用段覆盖,将每CPU 67 相对地址重定位到处理器适当的每CPU区域。所以对每CPU基址的重定位是通过段寄存器前缀 120 使用每CPU变量的偏移量(&x!),并返回属于当前执行处理器的每CPU变量的地址。 122 的处理器编号。相反,本地每CPU区域的偏移量只是简单地添加到每CPU偏移量上。 126 器的每CPU数据。 128 每CPU变量和偏移量 131 每CPU变量相对于每CPU区域的起始点是有偏移的。它们没有地址,尽管代码里看起来像有一 141 在每CPU操作的上下文中,上面表达式说明x是一个每CPU变量。大多数this_cpu操作都需要一 246 远程CPU,并对其每CPU区域进行更新。 [all …]
|
H A D | workqueue.rst | 151 的CPU上跳转。 178 CPU密集型工作项的执行。 214 消耗CPU 5ms,然后睡眠10ms,然后在完成之前再次消耗CPU 5ms。 220 0 w0 starts and burns CPU 224 20 w1 starts and burns CPU 227 35 w2 starts and burns CPU 234 0 w0 starts and burns CPU 236 5 w1 starts and burns CPU 248 0 w0 starts and burns CPU 250 5 w1 starts and burns CPU [all …]
|
H A D | refcount-vs-atomic.rst | 38 子性和程序顺序(program order, po)关系(在同一个CPU上)。它保证每个 42 强(完全)内存顺序保证在同一CPU上的所有较早加载和存储的指令(所有程序顺序较早 44 同一CPU上储存的程序优先较早的指令和来自其他CPU传播的指令必须在该CPU执行任何 45 程序顺序较后指令之前传播到其他CPU(A-累积属性)。这是用smp_mb()实现的。 47 RELEASE内存顺序保证了在同一CPU上所有较早加载和存储的指令(所有程序顺序较早 48 指令)在此操作前完成。它还保证同一CPU上储存的程序优先较早的指令和来自其他CPU 52 ACQUIRE内存顺序保证了同一CPU上的所有后加载和存储的指令(所有程序顺序较后 53 指令)在获取(acquire)操作之后完成。它还保证在获取操作执行后,同一CPU上 54 储存的所有程序顺序较后指令必须传播到所有其他CPU。这是用 59 储的控制依赖没有使用任何明确的屏障来实现,而是依赖于CPU不对存储进行猜测。这只是 [all …]
|
H A D | local_ops.rst | 19 如何正确使用这些操作。它还强调了在内存写入顺序很重要的情况下,跨CPU读取 33 本地原子操作的目的是提供快速和高度可重入的每CPU计数器。它们通过移除LOCK前 34 缀和通常需要在CPU间同步的内存屏障,将标准原子操作的性能成本降到最低。 36 在许多情况下,拥有快速的每CPU原子计数器是很有吸引力的:它不需要禁用中断来保护中 40 本地原子操作只保证在拥有数据的CPU上的变量修改的原子性。因此,必须注意确保只 41 有一个CPU写到 ``local_t`` 的数据。这是通过使用每CPU的数据来实现的,并确 43 数据都是允许的:这样它就会显得与所有者CPU的其他内存写入顺序不一致。 66 * *只有* 这些变量的CPU所有者才可以写入这些变量。 72 CPU变量和进行实际的本地操作之间不会被迁移到不同的CPU。 118 所看到的跨CPU的数据必须被认为是相对于拥有该数据的CPU上发生的其他内存写入来 [all …]
|
/openbmc/linux/Documentation/translations/ko_KR/ |
H A D | memory-barriers.txt | 179 CPU 1 CPU 2 213 CPU 1 CPU 2 1041 CPU 1 CPU 2 1087 CPU 1 CPU 2 1128 CPU 1 CPU 2 1163 CPU 1 CPU 2 1198 CPU 1 CPU 2 1281 CPU 1 CPU 2 1308 CPU 1 CPU 2 1375 CPU 1 CPU 2 CPU 3 [all …]
|
/openbmc/linux/Documentation/translations/zh_CN/mm/ |
H A D | mmu_notifier.rst | 45 CPU-thread-2 {} 46 CPU-thread-3 {} 52 CPU-thread-2 {} 53 CPU-thread-3 {} 59 CPU-thread-2 {} 60 CPU-thread-3 {} 67 CPU-thread-3 {} 73 CPU-thread-2 {} 80 CPU-thread-2 {} 81 CPU-thread-3 {} [all …]
|
H A D | hmm.rst | 19 地址,这意味着 CPU 上的任何有效指针也是该设备的有效指针。这对于简化高级异构计算的使用变得 23 部分中,我揭示了许多平台固有的硬件限制。第三部分概述了 HMM 设计。第四部分解释了 CPU 页 68 致。但是,它只允许设备对主存储器进行一组有限的原子操作。这在另一个方向上更糟:CPU 82 存在设备使用时迁移到设备内存(在迁移时阻止 CPU 访问)。 104 请注意,任何 CPU 对设备页面的访问都会触发缺页异常并迁移回主内存。例如,当支持给定CPU 132 页异常代码路径,就像 CPU 缺页异常一样。 135 范围中的一个地址。HMM 提供了一组标志来帮助驱动程序识别特殊的 CPU 页表项。 219 我们只需要确保没有人试图从 CPU 端映射这些页面。 309 入到CPU的页表中。如果一个CPU线程在同一页面上发生异常,这可能会失败。然而,页 314 ``struct page`` ,最终完成CPU端的迁移。 [all …]
|
H A D | numa.rst | 18 从硬件角度看,NUMA系统是一个由多个组件或装配组成的计算机平台,每个组件可能包含0个或更多的CPU、 28 所有的内存都是可见的,并且可以从连接到任何单元的任何CPU中访问,缓存一致性是由处理器缓存和/或 31 内存访问时间和有效的内存带宽取决于包含CPU的单元或进行内存访问的IO总线距离包含目标内存的单元 32 有多远。例如,连接到同一单元的CPU对内存的访问将比访问其他远程单元的内存经历更快的访问时间和 42 上,对一些架构的细节进行了抽象。与物理单元一样,软件节点可能包含0或更多的CPU、内存和/或IO 47 的任何CPU重新分配到代表有内存的单元的节点上。因此,在这些架构上,我们不能假设Linux将所有 48 的CPU与一个给定的节点相关联,会看到相同的本地内存访问时间和带宽。 66 默认情况下,Linux会尝试从执行请求的CPU被分配到的节点中满足内存分配请求。具体来说,Linux将试 85 内存的节点,“本地内存节点”——CPU节点的分区列表中的第一个区域的节点——将不是节点本身。相反,它 91 得到通知说该节点没有空闲内存。例如,当一个子系统分配每个CPU的内存资源时,通常是这种情况。 [all …]
|
/openbmc/linux/Documentation/translations/zh_CN/driver-api/ |
H A D | io_ordering.rst | 29 CPU A: val = readl(my_status); 30 CPU A: ... 31 CPU A: writel(newval, ring_ptr); 35 CPU B: val = readl(my_status); 36 CPU B: ... 37 CPU B: writel(newval2, ring_ptr); 46 CPU A: val = readl(my_status); 47 CPU A: ... 48 CPU A: writel(newval, ring_ptr); 53 CPU B: val = readl(my_status); [all …]
|
/openbmc/linux/arch/sparc/kernel/ |
H A D | cpu.c | 72 CPU(-1, NULL) 96 CPU(-1, NULL) 111 CPU(-1, NULL) 120 CPU(-1, NULL) 135 CPU(-1, NULL) 148 CPU(-1, NULL) 158 CPU(-1, NULL) 167 CPU(-1, NULL) 176 CPU(-1, NULL) 189 CPU(-1, NULL) [all …]
|
/openbmc/linux/Documentation/translations/zh_TW/ |
H A D | io_ordering.txt | 36 CPU A: val = readl(my_status); 37 CPU A: ... 38 CPU A: writel(newval, ring_ptr); 42 CPU B: val = readl(my_status); 43 CPU B: ... 44 CPU B: writel(newval2, ring_ptr); 53 CPU A: val = readl(my_status); 54 CPU A: ... 55 CPU A: writel(newval, ring_ptr); 60 CPU B: val = readl(my_status); [all …]
|
/openbmc/linux/Documentation/translations/zh_CN/admin-guide/ |
H A D | cputopology.rst | 11 如何通过sysfs将CPU拓扑导出 50 7) topology_sibling_cpumask: 仅入参CPU 51 8) topology_core_cpumask: 仅入参CPU 52 9) topology_cluster_cpumask: 仅入参CPU 53 10) topology_die_cpumask: 仅入参CPU 54 11) topology_book_cpumask: 仅入参CPU 55 12) topology_drawer_cpumask: 仅入参CPU 61 kernel_max: 内核配置允许的最大CPU下标值。[NR_CPUS-1] 68 possible: 已被分配资源的CPU,如果它们CPU实际存在,可以上线。 76 在本例中,系统中有64个CPU,但是CPU 32-63超过了kernel_max值,因为NR_CPUS配置项是32, [all …]
|
/openbmc/qemu/docs/specs/ |
H A D | acpi_cpu_hotplug.rst | 14 CPU present bitmap for: 18 - One bit per CPU. Bit position reflects corresponding CPU APIC ID. Read-only. 24 to notify OS about CPU hot-add events. CPU hot-remove isn't supported. 46 The last stored value in 'CPU selector' must refer to a possible CPU, otherwise 100 contains 'CPU selector' value of a CPU with pending event[s] 127 selected CPU device 153 selected CPU ('CPU selector' value). 154 If no CPU with events found, the current 'CPU selector' doesn't 165 architecture specific CPU ID value for currently selected CPU. 196 #. CPU bitmap always has bit #0 set, corresponding to boot CPU. [all …]
|
/openbmc/linux/Documentation/translations/zh_CN/cpu-freq/ |
H A D | cpu-drivers.rst | 30 1.2 Per-CPU 初始化 43 如果,你刚刚得到了一个全新的CPU/芯片组及其数据手册,并希望为这个CPU/芯片组添加cpufreq 51 运行在正确的CPU和正确的芯片组上。如果是,则使用cpufreq_register_driver()向 74 .get - 返回CPU的当前频率。 76 .bios_limit - 返回HW/BIOS对CPU的最大频率限制值。 78 .exit - 一个指向per-policy清理函数的指针,该函数在CPU热插拔过程的CPU_POST_DEAD 97 1.2 Per-CPU 初始化 100 每当一个新的CPU被注册到设备模型中,或者当cpufreq驱动注册自身之后,如果此CPU的cpufreq策 105 如果有必要,请在你的CPU上激活CPUfreq功能支持。 155 大多数cpufreq驱动甚至大多数CPU频率升降算法只允许将CPU频率设置为预定义的固定值。对于这些,你 [all …]
|
/openbmc/linux/Documentation/driver-api/ |
H A D | io_ordering.rst | 19 CPU A: val = readl(my_status); 20 CPU A: ... 21 CPU A: writel(newval, ring_ptr); 25 CPU B: val = readl(my_status); 26 CPU B: ... 27 CPU B: writel(newval2, ring_ptr); 36 CPU A: val = readl(my_status); 37 CPU A: ... 38 CPU A: writel(newval, ring_ptr); 43 CPU B: val = readl(my_status); [all …]
|
/openbmc/linux/Documentation/translations/zh_CN/arch/arm64/ |
H A D | booting.txt | 41 这个术语来定义在将控制权交给 Linux 内核前 CPU 上执行的所有软件。 153 - 主 CPU 通用寄存器设置 159 - CPU 模式 184 这可能要根据具体实现来定义初始化过程,以使能每个CPU上对维护操作的 208 必要条件描述适用于所有 CPU。所有 CPU 必须在同一异常级别跳入内核。 210 引导装载程序必须在每个 CPU 处于以下状态时跳入内核入口: 212 - 主 CPU 必须直接跳入内核映像的第一条指令。通过此 CPU 传递的设备树 219 - enable-method 为 “spin-table” 的 CPU 必须在它们的 CPU 228 因此 CPU 须在跳转前将所读取的值转换为其本身的端模式。 234 CPU_ON 调用来将 CPU 带入内核。 [all …]
|
/openbmc/qemu/qapi/ |
H A D | machine-target.json | 12 # Virtual CPU model. 14 # A CPU model consists of the name of a CPU definition, to which delta 67 # usually calculated using e.g. CPU features or CPU generations. 135 # Usually, a CPU model is compared against the maximum possible CPU 189 # migration-safe CPU model (see "static" CPU model expansion for 193 # model out two CPU models. The created CPU model will be identical 195 # the created CPU model is guaranteed to run where the given CPU 269 # Expands a given CPU model, @model, (or a combination of CPU model + 323 # Virtual CPU definition. 357 # CPU model attributes that prevent the CPU from running. If the QOM [all …]
|
/openbmc/linux/Documentation/translations/zh_TW/arch/arm64/ |
H A D | booting.txt | 45 這個術語來定義在將控制權交給 Linux 內核前 CPU 上執行的所有軟體。 157 - 主 CPU 通用寄存器設置 163 - CPU 模式 188 這可能要根據具體實現來定義初始化過程,以使能每個CPU上對維護操作的 212 必要條件描述適用於所有 CPU。所有 CPU 必須在同一異常級別跳入內核。 214 引導裝載程序必須在每個 CPU 處於以下狀態時跳入內核入口: 216 - 主 CPU 必須直接跳入內核映像的第一條指令。通過此 CPU 傳遞的設備樹 223 - enable-method 爲 「spin-table」 的 CPU 必須在它們的 CPU 232 因此 CPU 須在跳轉前將所讀取的值轉換爲其本身的端模式。 238 CPU_ON 調用來將 CPU 帶入內核。 [all …]
|
/openbmc/linux/Documentation/arch/x86/ |
H A D | topology.rst | 114 CPU. 172 -> [thread 1] -> Linux CPU 1 174 -> [thread 1] -> Linux CPU 3 179 -> [thread 1] -> Linux CPU 2 181 -> [thread 1] -> Linux CPU 3 203 -> [thread 1] -> Linux CPU 1 205 -> [thread 1] -> Linux CPU 3 208 -> [thread 1] -> Linux CPU 5 210 -> [thread 1] -> Linux CPU 7 215 -> [thread 1] -> Linux CPU 4 [all …]
|