多核时如何让 ClockLimit 在 < CPULimit 时也起效？

[BoYanZh]

go-judge/worker/waiter.go

Line 23 in 6211423

clockTimeLimit = w.timeLimit

根据这里 ClockLimit 会被强制设置成至少为 CPULimit，但在编译 Rust 的场景下我希望能真正限制到 ClockLimit，因为在多核机器上 CPU Time 可以达到 Clock Time 的 10 倍以上，有什么别的解决方法吗？或者能否去掉这个限制？

[criyle]

这个限制是基于程序至少被分配到一个 CPU 核心做出的。在多核场景下，当 CPU time 达到限制的时候，会在 clock time 之前结束任务。如果考虑到 CPU 争用的情况 （例如同时编译多个 Rust 程序的场景），实际分配的 CPU 减少的情况下，CPU time 和 clock time 的比例可能会降低。如果需要改动这个逻辑，可以设计为仅在非零是覆写或者仅在小于 CPU time / CPU count 时覆写。

[BoYanZh]

我现在是cpulimit和clocklimit都给了值，现在的机器上cargo build会做到cpu time 120s，wall-clock time 15s，为了能build成功我得给cpulimit开120s，但这时候clocklimit也被设成120s导致出了问题退出很慢。我觉得可以改成clockTimeLimit非0的时候就不再把他设成cpuTimeLimit了，直接用用户提供的值。

[criyle]

这是一个解决方案。同时我也在思考有没有什么方案可以减少 CPU 使用，比如能提前编译某些库，提供一些编译缓存之类的。

[BoYanZh]

对，目前我这还有个问题就是比如说我host machine里有~/.cargo我希望能直接挂在到sandbox的/w/.cargo里，这样我只要设置HOME就可以，但因为/w是tmpfs似乎没法直接在mount.yaml里做到？现在只能把~/.cargo挂载到/.cargo然后手动设置CARGO_HOME到那里。
缓存方面感觉github actions的actions/cache的那套用unique key来创建和还原cache挺成熟的，但不太适合集成到go-judge里。

[criyle]

因为沙箱复用的关系 tmpfs 会在运行后清空，/w 下的挂载也会收到影响。至于 github actions 那一套是给信任用户使用的，如果用户提交的程序能够修改共享的缓存，那就需要考虑到安全的问题。

[BoYanZh]

我本来尝试在initCmd里把/.cargo给soft link到/w/.cargo下，但好像也不行，这个有办法在挂载的时候就做到吗？
对，我是觉得cache是得额外一层的事情，应该没法直接在go-judge里加上。

[criyle]

initCmd 仅在初次创建容器的时候运行，在复用的时候就清空 /w 了。使用环境变量指定路径的话会更好些。