Summary: | cpuset(1) by twice kill SMP functionality | ||
---|---|---|---|
Product: | Base System | Reporter: | Oleg Ginzburg <olevole> |
Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
Status: | Closed Feedback Timeout | ||
Severity: | Affects Only Me | CC: | jhb |
Priority: | Normal | ||
Version: | Unspecified | ||
Hardware: | Any | ||
OS: | Any |
Description
Oleg Ginzburg
2011-12-24 14:20:09 UTC
> It leads to a situation when one core is 100 % occupied, the others
> core - 100% idle. There is no possibility to correct a situation
> without reboot
In particular this also applies to FreeBSD 10.0-CURRENT and on both
schedulers (ULE and 4BSD).
We have to check - if somehow the situation changed after the change in the ULE scheduler? Right now I notice the same situation for 9.2-stable, but only with SCHED_ULE, SCHED_4BSD looks working. See http://lists.freebsd.org/pipermail/freebsd-stable/2014-January/076894.html (cpuminer calls cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_CPUSET), so few restarts show the bug) I suspect you were using 'cpuset -c -l N -p <PID>' rather than 'cpuset -l N -p <PID>' in which case this is working as designed. When you use '-c', you change the mask of the global cpuset that the process belongs to, not the mask that is private to the process itself. The cpuminer bug referenced was exactly due to this (it was using CPU_WHICH_CPUSET incorrectly which is identical to using cpuset -c) -- John Baldwin |