bin.pan

我看文档中的示例，也是这个效果，请问这个是什么机制呢？

另外，还有个疑问： 节点的 CPU 是 48 core, 节点上已运行的进程占用了部分 cpu，但是 kcnr 中统计的 reclaimed 资源还是 48 core, reclaimed的总量和节点的总量保持一致， 也就是说没有排除节点上已使用的CPU，请问这里 reclaimed资源的统计方式什么呢？

此外，还有个疑问： 创建 shared-normal-pod pod后，reclaimed_millicpu 从 48 core减少到 42 core, 一共少了6 core, 看文档解析说： 4 core 是预留资源，请问这样设计的目的是什么呢？这个 4core 可以通过配置修改吗？ 这个pod实际只使用了 1 core cpu, request 和 limit 也是 1core, 为什么计算时减少了2core呢？

> > 此外，还有个疑问： 创建 shared-normal-pod pod后，reclaimed_millicpu 从 48 core减少到 42 core, 一共少了6 core, 看文档解析说： 4 core 是预留资源，请问这样设计的目的是什么呢？这个 4core 可以通过配置修改吗？ 这个pod实际只使用了 1 core cpu, request 和 limit 也是 1core, 为什么计算时减少了2core呢？ >...

> > 另外，还有个疑问： 节点的 CPU 是 48 core, 节点上已运行的进程占用了部分 cpu，但是 kcnr 中统计的 reclaimed 资源还是 48 core, reclaimed的总量和节点的总量保持一致， 也就是说没有排除节点上已使用的CPU，请问这里 reclaimed资源的统计方式什么呢？ > > 如[官网文档](https://gokatalyst.io/docs/getting-started/colocation-quick-start/#reporting-reclaimed-resource)所述： > > ``` > reclaim cpu = allocatable...

@caohe 非常感谢您的耐心解答。我还有一个疑问，我对一个 shared_cores pod(stress) 持续施压，发现最后Reclaimed资源一直稳定在 4core，不会再继续降低，请问这又是什么机制呢？

> > 另外，还有个疑问： 节点的 CPU 是 48 core, 节点上已运行的进程占用了部分 cpu，但是 kcnr 中统计的 reclaimed 资源还是 48 core, reclaimed的总量和节点的总量保持一致， 也就是说没有排除节点上已使用的CPU，请问这里 reclaimed资源的统计方式什么呢？ > > 如[官网文档](https://gokatalyst.io/docs/getting-started/colocation-quick-start/#reporting-reclaimed-resource)所述： > > ``` > reclaim cpu = allocatable...

> > @caohe 非常感谢您的耐心解答。我还有一个疑问，我对一个 shared_cores pod(stress) 持续施压，发现最后Reclaimed资源一直稳定在 4core，不会再继续降低，请问这又是什么机制呢？ > > @flpanbin 我理解这里其实在另一个 issue 里提到了 [#594 (comment)](https://github.com/kubewharf/katalyst-core/issues/594#issuecomment-2134501366) ？ @pendoragon 不好意思，这里没有描述清楚，其实是想了解下 `minReclaimedResourceForReport` 设计的目的是什么，因为实际的 reclaimed 资源可能是小于这个阈值的，但是从上报结果上看两者是不一致的。令人比较疑惑。

@pendoragon 了解了，感谢！还想再请教下： 1. system_cores 会影响 reclaim 资源的计算吗？ 2. system_cores 的 pod是会分配除独占外所有的core吗？比如节点是16 core， shared_cores 使用1-4，system_cores 是分配1-16吗？（我验证结果是这样，想再确认下）。

Thank you for your contribution. /lgtm @calvin0327 PTAL