On Tue, Dec 5, 2023 at 4:56 PM Daniel Lange <dla...@debian.org> wrote:
> The rationale is given on top of the patch that you found > (001_remove_lxc_special_handling.patch) and the matching commit > > < > https://github.com/htop-dev/htop/commit/11318b5ef6de6b2f80186a888cd5477e0ff167bb > > > > We don't have any better LXC handling, so I opted for showing the > reality (visible CPUs that the container cannot schedule load on) over > the bugs we had otherwise. > Thank you, Daniel, for your quick response. Probably depends on the view point, but the reality for me is that this container is able to use two cpus. The fact that all physical cores are showing up is misleading - especially as htop is often used for a "quick view" on resource usage. > You created upstream #1332 but did not try the latest htop main branch, > did you? I suspect it will be the same but would be nice to confirm. > NB: There has been some improvements in the cgroup name handling for LXC > since the 3.2.2 release. > The current main branch shows the same behaviour: All physical cores are showing up. Here is a comparison. htop 3.2.1 shows 2 cpus, 31 tasks, 66 threads. htop uses roughly 0.7% CPU htop 3.2.2 shows 2 cpus, 31 tasks, 66 threads. htop uses roughly 1.3% CPU htop 3.2.2 with that patch shows 16 cpus, 31 tasks, 66 threads. htop uses between 5.3% and 10.6% CPU htop current main branch shows 16 cpus, 31 tasks, 66 threads. htop uses between 5.3% and 10.6% CPU I guess I fail to see the reason why this patch (removing LXC handling) was implemented. What was the bug being the reason to apply this patch? Let me know If I can help with some additional tests in my environments.
