On 16.01.2014 11:20, Alexander wrote: > > > 14.01.2014, 22:32, "Alexander" <ags18_at_yandex.ru>: >> 14.01.2014, 20:14, "Subbsd" <subbsd_at_gmail.com>: >> >>> On Tue, Jan 14, 2014 at 7:43 PM, Andrey Chernov <ache_at_freebsd.org> wrote: >>>> On 14.01.2014 17:01, Alexander wrote: >>>>> on Freebsd 9.2 x64 on 5 different PCs I installed net-p2p/cpuminer >>>>> from ports and by "pkg install" - result is the same - minerd mines >>>>> only on one core regardless of "--threads" option. >>>> ... >>>>> # top -P >>>>> CPU 0: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle >>>>> CPU 1: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle >>>>> CPU 2: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle >>>>> CPU 3: 0.0% user, 100% nice, 0.0% system, 0.0% interrupt, 0.0% idle >>>> This is SCHED_ULE bug, I see _all_ processes (not minerd only in >>>> particular) stuck to the last CPU too (top's 'C' column is equal to the >>>> last CPU and never changes), latest -stable i386. It disappears for me >>>> switching to SCHED_4BSD. >>>> >> >> reboot didn't help (try on 3 different PCs) > ... > minerd was started from cron after reboot immediately and broke SMP, so when I disable minerd from cron and reboot - SMP works fine. > I think Andrey Chernov said here the reason http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/163585#reply3 > So this bug is alive - on 9.1 and 9.2 x64 releases. > I didn't try SCHED_4BSD yet, cause don't wont to use not-generic kernel because of mining only, but for interest I'll try it on one machine on this weekends. I just try it on latest x64 -current, result is exact the same: the bug exist with SCHED_ULE and not with SCHED_4BSD. Something is very wrong in SCHED_ULE+cpuset_setaffinity chain.Received on Fri Jan 17 2014 - 06:47:32 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:46 UTC